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?
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).
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.
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)?
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.
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.
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.
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)”.
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.
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).