Thanks. Now I start to see how this thing works. My previous worry of
data loss is unnecessary. Cheers, -Cedric
Aaron Akihisa Kagawa wrote:
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
