Hello I ran the same example on Lyon machines (ccali.in2p3.fr), and problem is still there. But now if I run my routine under ROOT version 3.03/09 instead 3.10/02, then there isn't anymore this time shift (at Lyon and on my local machine), ie plot begins as expected at minight 00:00. Moreover, in both case (for the two root versions), I get the same result of the mktime() function: root [0] .L test_Datime.cc root [1] UInt_t year = 2004-1995; root [2] UInt_t month = 7; root [3] UInt_t day = 1; root [4] UInt_t hour = 0; root [5] UInt_t min = 0; root [6] UInt_t sec = 0; root [7] root [7] struct tm tp; root [8] tp.tm_year = year+95; root [9] tp.tm_mon = month-1; root [10] tp.tm_mday = day; root [11] tp.tm_hour = hour; root [12] tp.tm_min = min; root [13] tp.tm_sec = sec; root [14] tp.tm_isdst = -1; root [15] time_t t = mktime(&tp); root [16] cout<<"time "<<t<<endl; time 1088632800 root [17] char *dt= asctime(&tp); root [18] dt (char* 0x40cb6de0)"Thu Jul 1 00:00:00 2004\n" So mktime() function gives time in UTC (2 hours of less than my local time), as expected: marfil:~>date -R Tue, 20 Jul 2004 12:28:53 +0200 marfil:~>date -u Tue Jul 20 10:28:56 UTC 2004 So maybe this problem lies in gStyle->SetTimeOffset() and not in TDaTime::Convert(). However, how can I know if it is a daylight savings time effect? Thanks very much for help, Stephanie PS: on linux machine, environnement variable TZ is not defined by defaut. Damir Buskulic wrote: > Hi > > A suggestion : maybe it is a summer/winter time (daylight savings > time) effect ? > > Damir > > Le 9 juil. 04, à 16:45, Stephanie Escoffier a écrit : > > Dear Root team, > > I don't understand behaviour of TDatime::Convert() function, and > more precisely why there is one hour extra. > In practice, if I plot data with starting date of July 9, 2004 at > 00:00 every 15 mns, TGraph have axis starting one hour before. > I put an example below. > If I request GMT time, so there is a shift of 3 hours. > Maybe it is a problem of time zone effect, but TDatime::Convert() > function should be transparent to this, like a black box. > Moreover, if starting date is Jan 1, 2004, so there is no shift. > > And now if I look at result of Convert() function for the date of > Jan 1, 1995, which is the number of seconds since Jan 1, 1970, it > should be an integer in days. And there is one hour of shift again. > > root [0] TDatime *da = new TDatime(1995,1,1,0,0,0); > root [1] UInt_t a = da->Convert(); > root [2] a > (unsigned int)788914800 > root [3] Double_t b = (Double_t)a; > root [4] Double_t days = b/3600/24; > root [5] days > (Double_t)9.13095833333333394e+03 > root [6] (days-int(days))*24. > (double)2.30000000000145519e+01 > > > I found in Roottalk digest a mail dealing with the same problem > (http://root.cern.ch/root/roottalk/roottalk03/2746.html), and it > was said that this problem was fixed. So my question is: Does this > problem come from the time zone effect? In this case, how can I > draw data with correct date, knowing that add one hour to my data > doesn't resolve the problem since GMT conversion is either 1 hour > or 0 hour according to summer or winter? > > I am using ROOT 3.10/02 on Red Hat 7.2 > > Thank you, > regards, > > Stephanie >
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET