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 >
