At 08:10 AM 8/25/2006, Philip Johnson wrote:
Sorry, but I am so missing the problem you are seeing here. From my
perspective, the timezonechanger changes the UTC values so that the
PST server sees the entries at the same as they were in HST.
Correct.
The non-tstamp UTC values, when retrieved in the test case code,
will be fed into a "real time" corrector that returns new values
that are equivalent to the original HST times. In this way, the
test data UTC values are always "seen" as HST days and times.
I suppose this could work.
What am I misinterpreting?
I think the confusion was, I thought you mentioned that only the Test
Case Java Code would be affected by the incorrect _tstamp_ UTC
values. Which is not correct. Now I see that you are saying only the
NON-tstamp UTC values. This could possibly work. I say possibly
because it all depends on how the 'analysis' code (DailyProjectData,
DailyAnalysis, etc) handle these NON-tstamp UTC values. For example,
what if the latest snapshot was restricted to be on the same day that
the DailyProjectData was instantiated for.
Anyway, I think its worth a shot to try to handle the NON-tstamp UTC
values with your proposed method.
thanks, Aaron
At 08:10 AM 8/25/2006, Philip Johnson wrote:
----- Original Message -----
From: Aaron Akihisa Kagawa <[EMAIL PROTECTED]>
Date: Thursday, August 24, 2006 2:35 pm
Subject: Re: [HACKYSTAT-DEV-L] TimeZoneChanger
To: Philip Johnson <[EMAIL PROTECTED]>
Cc: [email protected]
> Hm.
>
> Say for example, we are in PST with a 3 hour difference and our
> test data has HST timestamps from 8:00PM to 10:00PM for 2006-08-23.
> With the timezone change the dates will change to 11:00PM on 2006-
> 08-23 to 1:00AM on 2006-03-24. Say we are doing a test on
> DailyProjectData for 2006-08-23, which should access only one day
> to get the data (although I think it doesn't actually check the
> value of the date.).
>
> Would solution (2) still work? Logically it shouldn't work. It
> sort of depends how the data is processed in the Analysis code.
Sorry, but I am so missing the problem you are seeing here. From my
perspective, the timezonechanger changes the UTC values so that the
PST server sees the entries at the same as they were in HST.
The non-tstamp UTC values, when retrieved in the test case code,
will be fed into a "real time" corrector that returns new values
that are equivalent to the original HST times. In this way, the
test data UTC values are always "seen" as HST days and times.
What am I misinterpreting?
Cheers,
Philip
