Re: [HACKYSTAT-DEV-L] TimeZoneChanger Question

[Philip Johnson]

Hi Cedric,

TimeZoneChanger.java
Line 174-182 in processSensorDataFile() method
    if (!day.equals(day2)) {
        throw new TimeZoneChangerException("The calculated offset causes a 
change in
day. "
          + "[day(from file)=" + day + "| "
          + "originalTimeStamp=" + timeStamp + ", day=" + 
Day.getInstance(timeStamp)
          + ", date=" + new Date(timeStamp)
          + " | adjustedTimeStamp=" + adjustedTimeStamp + ", day=" + day2
          + ", date=" + new Date(adjustedTimeStamp)
          + "]");
      }

It seems that this methods throws away those sensor data entries if timestamp
adjustment causes a change in the day. Does that mean we are losing those 
entries in
testing files forever?

Well, "forever" is a very long time. :-)  No, I think we just lose those entries for that 
test run.  I think Aaron might have just taken the simple way out here, rather than 
figuring out which day (either +1 or -1) to retrieve and add the data to.

But, given that I know what Jira issue that you're working on, might I suggest that a 
potentially simpler way to approach the problem is to change the test cases to not use 
hard-coded raw UTC values?  In other words, the goal of the TimeZoneChanger mechanism is 
to make sure that a test that assumes that data whose timestamp is interpreted as 9:30am 
on Dec. 12 will be interpreted that way regardless of where the server is located.  So, 
instead of using a hard-coded raw UTC value in your test case, an alternative is to 
determine what time you are worried about, then test for that (or else compute the UTC 
value corresponding to that time on the fly, which will be in the server's local time 
zone.)

Cheers,
Philip