Re: [ROOT] TDatime

From: Fons Rademakers (Fons.Rademakers@cern.ch)
Date: Tue Jul 20 2004 - 14:49:04 MEST


Hi Stephanie,

  day light savings time is specified as not being available in ROOT
(tm_isdst = -1) which then when passed to functions like ctime() will
result in the system TZ to be taken into account to print the correct
DST corrected local time:

root [5] TDatime d
root [6] UInt_t t = d.Convert()
(const unsigned int)1090327521
root [7] time(0)
(const long)1090327526
root [8] d.AsString()
(const char* 0x42133860)"Tue Jul 20 14:45:21 2004"
root [9] ctime(&t)
(const char* 0x42133860)"Tue Jul 20 14:45:21 2004\n"

show that TDatime::Convert() and time() give the same result (took me 5
sec to type the time(0) command), taking into account DST via the
system.

It is very likely a time axis layout issue.

Cheers, Fons.




On Tue, 2004-07-20 at 12:37, Stephanie Escoffier wrote:
> 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
> >
-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch              Phone: +41 22 7679248
WWW:    http://www.rademakers.org/fons/      Fax:   +41 22 7679480



This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET