I guess I'm a little out of the loop here, but I don't quite understand the problem.
If I remember correctly, the purpose of the TimeZoneChanger is to change the timestamps of the data based on the timezone such that there is no change in time. So, 9:00 AM HST is 9:00 PST. That way when we use the data in different timezones we can still use 9:00 AM. I think the check that you are referring to is a sanity check. If my TimeZoneChanger incorrectly adjust the time then it throws the exception but leaves the data changed. So, the data is not gone. It doesn't go anywhere (i think), it just has what I have determined to be a wrong timestamp. One possible cause of the error is sometimes the original data is incorrect. For example, the day represented in the filename (2006-01-02.xml) does not match the day in the timesamps. This could also cause that exception to be thrown. Anyway, with that being said, I'm not sure I understand your latest comment. By the way, what Jira issue are we basing this discussion on? thanks, Aaron ----- Original Message ----- From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> Date: Wednesday, August 23, 2006 4:48 pm Subject: Re: [HACKYSTAT-DEV-L] TimeZoneChanger Question To: [email protected] > Yes, loosing data for the test run, that's what I meant. I > exaggerated > that a little bit. > > If we run test cases in each of the 24 time zones, then everything > single test data entry will be lost at least once. In other words, > none > of the test case that relies on test data will pass in all of the > 24 > time zones, since at least in one of the time zone, the test case > will > find the required test data does not exist. > > After we get test cases pass in Eastern time zone, how can we be > sure > they will pass in, say, some African time zone, since different > test > data will be lost in different time zone. > > Cheers, > > Cedric > > > > > Philip Johnson wrote: > > 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 >
