Time offset in time axis

Nicola_Mori · July 7, 2015, 3:30pm

I’m plotting a certain quantity versus time. My dataset begins at 2012/03/14 00:00, and the UTC time stamp of the first event is 1331683214, which according to Python’s time library should be correct:

>>> import time
>>> time.gmtime(1331683214)
time.struct_time(tm_year=2012, tm_mon=3, tm_mday=14, tm_hour=0, tm_min=0, tm_sec=14, tm_wday=2, tm_yday=74, tm_isdst=0)

However on the X axis of my plot the data starts from 2012/03/14 01:00 when configuring the time axis with:

axis->SetTimeFormat("#splitline{%y/%m/%d}{%H:%M:%S}%F1970-01-01 00:00:00");

i.e. it seems that the UTC times are converted to date&time wit a 1 hour offset. I think it might be related to something like daylight savings but I can’t figure out how to turn it off. I tried with TAxis::SetTimeOffset with no success. Can someone please give me a hint about how to fix this?
Thanks.

couet · July 7, 2015, 3:32pm

Can you provide a small script reproducing the issue ?

Nicola_Mori · July 7, 2015, 3:44pm

The attached file has two functions: Plot reproduces my issue with my dataset starting at 2012/03/14 00:00, while Plot2 shows the same issue in a more simple case where UTC time is 0 so it should correspond to 1970/01/01 00:00 with the given time format string. As shown in the attached images, the axis of the produced plots are shifted by one hour.

Edit: note that I am in Italy, so my local time at the time of writing this post is ~ 17:44 (daylight savings is active here in this period of the year).

timePlot.C (585 Bytes)

Wile_E_Coyote · July 7, 2015, 4:15pm

The 1 hour difference in your case is most probably the difference between UTC (as returned by “gmtime”) and your “locatime” (which is related to your “time zone” which may also include “daylight saving” offset).

Try to add:
h->GetXaxis()->SetTimeOffset(0, "GMT");

BTW. To ROOT developers … taking about “GMT” is wrong, you should use “UTC” instead.

Nicola_Mori · July 7, 2015, 4:21pm

That was my guess. My consequent question is: is it possible to ignore daylight savings when converting the axis labels from UTC to date&time, since this would generate different labels when producing the same plot for the same data set in summer and in winter (which is far less than desirable)?

Nicola_Mori · July 7, 2015, 4:36pm

The suggestion in the modified reply from Coyote works. In my case I have place it after the call to SetTimeFormat also to redraw the axis with h->GetXaxis()->Draw() after setting the time offset. Previously I tried with SetTimeOffset but without the GMT option so it didn’t work.
Thanks to Coyote and couet for the support.

Wile_E_Coyote · July 7, 2015, 4:47pm

In general, I think (I’m no sure, though) that the local timezone specific offset that you get should only be related to the date/time which is used by the histogram, and it should be independent from the date/time when you draw it.
As an example, take “2012.3.14 0:0:14 UTC” and “2012.3.14 1:0:14 your_Italian_localtime” and you can see 1 hour difference (which is expected for March 14th).
Now execute “date” and “date -u” and you will see 2 hours difference which is expected in July.

Nicola_Mori · July 7, 2015, 4:55pm

I have a similar feeling. I think that a given UTC might correspond to different hours: for two countries in the same time zone there will be a 1 hour difference when converting a UTC value to local time if in only one country there is dayliight savings. For what I understand Root converts UTC neglecting the time zone but applying the daylight savings, at least in my case, since my colleagues in Japan didn’t see any issue on my very same data set although they are many time zones away and in Japan there’s no daylight savings.

Wile_E_Coyote · July 7, 2015, 5:05pm

That’s not what I said.
See “man localtime” for more explanations.
Try also to play with (observe the 2 hours difference which you get for any date/time in July):

    TH1I *h = new TH1I("h2", "h2", 10,
                       TDatime(2014, 07, 07, 12, 00, 00).Convert(),
                       TDatime(2014, 07, 07, 12, 10, 00).Convert());

and then try to play with (observe the 1 hour difference which you get for any date/time in January):

    TH1I *h = new TH1I("h2", "h2", 10,
                       TDatime(2014, 01, 07, 12, 00, 00).Convert(),
                       TDatime(2014, 01, 07, 12, 10, 00).Convert());

Note that the TDatime class has no support for time zones and the time is assumed to be in the local time of the machine where the object was created. Instead of “Convert()”, try also “Convert(kTRUE)”.

Nicola_Mori · July 7, 2015, 5:21pm

I see the two hour difference when calling Convert with and without kTRUE:

root [5] TDatime(2014, 07, 07, 12, 10, 00).Convert()
(const unsigned int)1404727800
root [6] TDatime(2014, 07, 07, 12, 10, 00).Convert(kTRUE)
(const unsigned int)1404720600

and one hour when converting a date when the daylight savings is not active in Italy, e.g.:

root [0] TDatime(2014, 03, 01, 12, 00, 00).Convert()
(const unsigned int)1393671600
root [1] TDatime(2014, 03, 01, 12, 00, 00).Convert(kTRUE)
(const unsigned int)1393668000

So finally I understand that TAxis uses TDatime and that if no time offset is specified then the conversion from UTC to date&time takes into account time zone and daylight savings. So when converting the UTC corresponding to 2012/03/14 00:00 GMT I got a one hour offset because of my time zone, not because of daylight savings. I must have misinterpreted what my Japanese colleagues did, then.
Thank you very much Coyote for the patience!

Edit: I see now your updated answer about TDatime not having support for time zones.

Wile_E_Coyote · July 7, 2015, 5:26pm

Just note that your time zone automatically INCLUDES daylight savings time rules which apply during some part of the year (so sometimes you’re 1 hour and sometimes 2 hours ahead of UTC).

Nicola_Mori · July 7, 2015, 5:28pm

Yes ,that’s what I wanted to show with my two examples in my previous post

Wile_E_Coyote · July 7, 2015, 5:30pm

So, now try to explain it to your Japanese colleagues.

Nicola_Mori · July 7, 2015, 5:33pm

I saw one plot from them with correct time scales, so I guess that either they already know about the SetTimeOffset trick or they might have used some more tricky procedure (like converting UTC to date&time with the standard C library and then building alphanumeric labels from those values).

Wile_E_Coyote · July 7, 2015, 5:37pm

Well, I could have expected that they know it already.
They are at least 7 hours ahead of you (in winter 8 hours).

Nicola_Mori · July 7, 2015, 5:40pm

[quote=“Wile E. Coyote”]Well, one could have expected that they know it already.
They are at least 7 hours ahead of you (in winter 8 hours). [/quote]
Good catch, man