...
[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