Option (2) : 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.
It's not the test cases only. All analysis code that accesses non-tstamp
UTC values needs to be wrapped. At least this is the case with
hackyApp_BuildAnalysis code. But, still, I think option (2) involves
much less effort than option (1).
Cheers,
Cedric
Philip Johnson wrote:
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
