...
[15:29:33 CDT(-0500)] <athena> no kidding.
[15:29:55 CDT(-0500)] <EricDalquist> time to figure out a way to fix this ...
[15:30:13 CDT(-0500)] <EricDalquist> the big problem is the people with a positive TZ offset
[15:30:22 CDT(-0500)] <EricDalquist> for the negative people they get a hole in their stats data
[15:30:25 CDT(-0500)] <EricDalquist> which isn't horrible
[15:30:32 CDT(-0500)] <EricDalquist> but for positive TZ offsets
[15:30:33 CDT(-0500)] <athena> yeah 
[15:30:37 CDT(-0500)] <EricDalquist> it will crash the aggregation
[15:30:38 CDT(-0500)] <athena> that's not so good
[15:30:52 CDT(-0500)] <EricDalquist> since data will already exist and be in a "closed" state
[15:31:02 CDT(-0500)] <EricDalquist> so that means to fix this
[15:31:12 CDT(-0500)] <EricDalquist> 1. disable stats aggregation on ALL machines in the environment
[15:31:30 CDT(-0500)] <EricDalquist> 2. run program to "fix" dates (not sure how that will work yet)
[15:31:38 CDT(-0500)] <EricDalquist> 3. roll out new portal code
[15:31:51 CDT(-0500)] <EricDalquist> 3 would enable aggregation again
[15:31:53 CDT(-0500)] <EricDalquist> grr
[15:32:13 CDT(-0500)] <athena> yeah :/
[15:37:29 CDT(-0500)] <EricDalquist> I have a feature I realized I forgot in the works
[15:37:48 CDT(-0500)] <EricDalquist> that essentially stops aggreattion from running where the code version is less than the db version
[15:38:07 CDT(-0500)] <EricDalquist> so if you upgrade one server of a cluster from 4.0.7 to 4.0.8
[15:38:11 CDT(-0500)] <EricDalquist> and that includes running db-update
[15:38:24 CDT(-0500)] <EricDalquist> only server(s) running 4.0.8 will do even aggreation
[15:38:37 CDT(-0500)] <athena> yeah
[15:38:38 CDT(-0500)] <EricDalquist> if that was in place now I think I could mostly automate this process
[15:38:43 CDT(-0500)] <EricDalquist> but it isn't
[15:38:47 CDT(-0500)] <athena> oh
[15:38:53 CDT(-0500)] <EricDalquist> the db versioning is there
[15:38:59 CDT(-0500)] <EricDalquist> but I forgot the check in the aggregator
[15:39:41 CDT(-0500)] <athena> ah
[15:39:54 CDT(-0500)] <EricDalquist> well ... I'll do a bunch of testing here
[15:40:00 CDT(-0500)] <EricDalquist> and see what I can figure out for a fix
[15:40:02 CDT(-0500)] <EricDalquist>
[16:30:51 CDT(-0500)] <EricDalquist> yup ... fixed the bug
[16:31:04 CDT(-0500)] <EricDalquist> and now all my event related dates jumped back in time by 5 hours
[16:31:06 CDT(-0500)] <EricDalquist>
[16:42:41 CDT(-0500)] <EricDalquist> uhg ... 8 columns across 5 tables affected by this TZ issue
[16:42:47 CDT(-0500)] <EricDalquist> this is not good at all
[16:43:20 CDT(-0500)] <EricDalquist> hrm
[16:43:33 CDT(-0500)] <EricDalquist> though setting the TZ to "jvm" isn't great either
[16:43:46 CDT(-0500)] <EricDalquist> I need to test what happens when the server crosses a DST boundary
[16:47:21 CDT(-0500)] <EricDalquist> so really it seems like storing stuff in UTC would be the best bet
[16:47:28 CDT(-0500)] <EricDalquist> the problem is this LocalDate ....
[16:47:39 CDT(-0500)] <EricDalquist> and its interaction with Date
[16:50:36 CDT(-0500)] <athena> yikes
[16:50:44 CDT(-0500)] <athena> that all sounds kind of concerning
[16:50:50 CDT(-0500)] <EricDalquist> yeah
[16:50:51 CDT(-0500)] <EricDalquist> it is
[16:50:54 CDT(-0500)] <EricDalquist> oh
[16:50:55 CDT(-0500)] <EricDalquist> ok
[16:50:56 CDT(-0500)] <EricDalquist> just tested
[16:51:02 CDT(-0500)] <EricDalquist> it is handling DST correctly
[16:51:08 CDT(-0500)] <EricDalquist> when using the jvm TZ
[16:51:10 CDT(-0500)] <EricDalquist> I believe
[16:51:11 CDT(-0500)] <EricDalquist> still
[16:51:16 CDT(-0500)] <EricDalquist> more testing is going to be needed
[16:51:25 CDT(-0500)] <EricDalquist> and probably a fairly complex java app will be needed to "fix" this
[16:51:28 CDT(-0500)] <EricDalquist>
[16:51:43 CDT(-0500)] <EricDalquist> oh well ... bus time