Interesting issue.
To recap, the problem we're dealing with is that we create "test" XML sensor data that is
stored in various "test" user accounts as part of our test development activities. When
we run tests, we write code that logs into these test user accounts and runs various
analyses which result in the retrieval and analysis of the pre-defined test sensor data.
Many of these test case analyses rely on the day and time associated with the sensor
data. As a simple example, a test case for the Daily Diary analysis might check to see
that there was editing activity between 9:30am and 9:35am on Tuesday, May 1, 2002. The
raw sensor data associates a UTC long (called the 'tstamp') with each sensor data item in
order to determine when the event associated with that sensor data time occurred.
The problem occurs when someone downloads the system, installs the server, and runs the
test cases from some other time zone. Now, the same UTC value for a sensor data entry
will be converted to a different time (and perhaps even a different day), depending upon
what the server's new local time zone is.
To solve this problem, Aaron implemented the TimeZoneChanger system which checks the time
zone associated with a server at startup time, and if the timezone is not HST,
TimeZoneChanger physically re-writes all of the *test* XML sensor data, modifying the
tstamp value so that if it corresponded to, say, 9:32am on Tuesday, May 1, 2002 in HST,
the tstamp value will still correspond to exactly that same day and time in the new local
time zone.
The problem, as Cedric points out, is that some test data might store UTC values as data
associated with non-tstamp fields. If these fields are accessed by test case code in a
new time zone, then they will represent a different time (or even different day) than
what they would represent in HST. This may or may not pose a problem. For example, if a
sensor data entry contains a "start time" and "end time" in UTC format, but the test case
checks to see that the difference (i.e. elapsed time) is exactly 100 milliseconds, then
the test will still succeed even though the UTC values no longer represent the same time
and day that they did in Hawaii.
I can see two ways to deal with this issue:
(1) Modify the SDT declaration syntax so that the SDT designer can state explicitly what
fields contain UTC values. Once that is done, and all of the SDTs are updated, we can
update TimeZoneChanger to inspect the SDT definition and thus do a more thorough job of
modifying UTC values.
(2) Provide a "real time" UTC value modifier as part of the TimeZoneChanger package. For
example, TimeZoneChanger.getLocalUtc(long) would return a long representing the UTC value
representing the same day and time in the current time zone as the UTC value that was
passed in HST. Of course, if the current time zone is also HST, then the method just
returns what it was passed. Once that method is available, then any test case code that
manipulates a non-tstamp UTC value and needs it corrected for the local timezone must
manually wrap the access to the the UTC sensor data in the TimeZoneChanger.getLocalUtc()
method so that it gets a time zone appropriate value.
What option do people prefer? Are there other options we should consider? (Personally, I
currently prefer (2) since I guesstimate that it requires about an order of magnitude
less effort to implement. :-)
Cheers,
Philip
--On Thursday, August 24, 2006 11:06 AM -1000 Aaron Akihisa Kagawa <[EMAIL PROTECTED]>
wrote:
Right. I think that is a true statement.
The problem is that tstamp is the only field guaranteed to be in all SDTs.
Maybe, if
the TimeZoneChanger knew the type of the attribute then it can change all
fields that
have a Date type. That sounds like the correct solution to the "total mess-up".
:)
thanks, Aaron
----- Original Message -----
From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]>
Date: Thursday, August 24, 2006 10:36 am
Subject: [HACKYSTAT-DEV-L] TimeZoneChanger
To: [email protected]
Ref: http://hackydev.ics.hawaii.edu:8080/browse/HACK-762
The TimeZoneChanger only changes "tstamp", it does not change other
time
related attributes in a sensor data entry.
For example: 2003-02-10 build data for testdataset reads:
<sensor>
<!-- build time 1:10am -->
<entry tstamp="1044875400000" tool="Testing"
result="Success"
failureType=""
failureMessage=""
runtimeStamp="1044875400000"
startTimeMillis="1044875400000"
endTimeMillis="1044875400001"
buildLocation="C:\buildanalysis\test"
buildTarget="N/A"
additionalData="configuration=Hackystat-
ALL,startType=FakeStartType,checkstyleRan=false,compilationRan=true,unittestRan=false,
failureModuleName=N/A" />
</sensor>
If I put my computer into GMT time zone, then this file got
rewritten by
TimeZoneChanger at Hackystat server startup time. The result is:
(1) tstamp is updated from 1044875400000 to 1044839400000.
(2) BUT runtimeStamp, startTimeMillis, endTimeMillis are NOT
updated.
Some of the analysis in hackyApp_BuildAnalysis compares
startTimeMillis
and endTimeMillis from Build sensor data (which is NOT changed)
and tstamp from Activity sensor data (which is changed).
The result is total mess-up.
Cheers,
Cedric
