Invalid time display on FreeBSD and MacOSX with ROOT 5.15.01

Dear ROOTers,
Using the latest development ROOT (5.15.01), I found that
time axis is not properly shown on FreeBSD (6.2) and MacOSX (10.4.8).
However, an older version ROOT (5.12/00f) can give correct results
with the same macro as I tried on the latest ROOT.

I attached a small macro (timetest.cpp). Uisng the macro,
I can obtain valid results with ROOT 5.12/00f on both FreeBSD
and MacOSX, while I could not get the same results with
the latest ROOT on both OSs.
I also attaced a correct result (timeaxis_5.12_00f_freebsd.gif)
and an incorrect one (timeaxis_5.15_01_freebsd.gif)
on FreeBSD (MacOSX also give the same results with ROOT 5.12
and 5.15, respectively).

Give me any idea.

Thank you.

timetest.cpp (376 Bytes)

With your macro I get also a wrong display on Linux the year is 1995 …
But if you re-execute the macro you get the right display. It is because you do the time offset setting too late. Your macro should be:

void timetest()
  TDatime sdate(2006, 5, 20, 0, 0, 0);
  TH1F *h = new TH1F("h", "", 86400, 0, 86400);
  cout << sdate.GetDate() " " << sdate.GetTime() << endl;
  TCanvas *c = new TCanvas("c", "", 50, 50, 800, 300);

Thank you for your quick reply.
I modified my small macro as you mentioned. However,
I got the same wrong result on FreeBSD and MacOSX,
using the latest ROOT (5.15.01).

I have no MAC OS machine myself but I just tried your macro (with my modification) on the MAC OS machine of one of my colleague and it works fine (with the latest ROOT version) on his machine (the year is 06 not 70).

Using the latest ROOT (5.15.01), the result seems to be better but
not valid. I attached a gif file of the resut.
In my macro, start date & time are 2006/5/20 0:0:0.
But, start date & time of the result are 2006/5/19 14:0:0.

I do not know if this problem is due to ROOT or OS.

On Linux we get the correct result (see attached picture). But On Mac we see also some difference. Not as big as you because CET is closer than Japan time. We will investigate.

Note that I have modified a bit the macro to make the picture easier to read:

void timetest()
  TCanvas *c = new TCanvas("c", "", 50, 50, 800, 300);
  TDatime sdate(2006, 5, 20, 0, 0, 0);
  TH1F *h = new TH1F("h", "", 86400, 0, 86400);
  cout << sdate.GetDate() " " << sdate.GetTime() << endl;

This problem is now fixed in the CVS head. Thanks to have reported it.

I use ROOT on FreeBSD 6.2 with gcc 3.4.6.

Using the ROOT 5.15.04 and the macro of “timetest.C” you quated , I got a wrong result. I attated the result as “timetest_5.15.04.png”.
In addition, “timeaxis2.C” in tutorials
also gives a wrong results. I also attatched the result as “root_5.15.04_timeaxis2.png”
Both macros provide correct results when I use ROOT 5.12.00f on FreeBSD.

I know that some changes in time axis have been introduced as shown in version 5.15.04 Release note. Thus are these case side effects ? or
special ones for FreeBSD ?

Yes the output you get with the macro timetest.cpp is clearly wrong. I have tried on the MAC we have here and this macro gives the right output. I have not yet found a FreeBSD machine to test there also. Does it work for you on MAC now ?

Yes. the “timetest.cpp” works well on Mac, using ROOT 5.15.01.
(Here I can not try the macro on the ROOT 5.15.04, since
I can not complie ROOT 5.15.04 source on my Mac(10.4.9, power pc).)
Thus the problem I encountered would be limited within

Any idea ?

I need to find a FreeBSD machine to test it. I’ll let you know.

We do not have a FeeBSD machine available here to make tests. When you submited the problem first, we assumed that MAC and FreeBSD had the same behavior (which is usually the case), and we applied the same patch for both. The fix was done in: TTimeStamp::GetZoneOffset()

On MAC, the value returned by this function had the opposite sign than on other machines.

It would be nice if you could help me to debug this problem on FreeBSD. Do you have the possibility to rebuild ROOT on a FreeBSD machine ?

Using TTimeStamp::GetZoneOffset() of ROOT 5.15.01 and 5.15.04 on
FreeBSD, I got 32400 and -32400, respectively. Probably, this would be
an expected behabior.
(On Mac, I got 32400 with ROOT 5.15.01.)
However, ROOT 5.15.01 on FreeBSD gives the same results as
ROOT 5.15.04 which I reported and attached graphs with timetest.cpp and timeaxis2.C yesterday.
Thus, the problem might not be casued by TTimeStamp::GetZoneOffset() .

Since I can rebuild my ROOT, I will report if succeding in fixing the problem.

The value expected by TGaxis::PaintAxis() on line 704 should be negative in your case, like for me. I get -3600 (one hour less from GMT). So if you get a negative value on FreeDSB and still see some problems, it means there is something else wrong. The debugging should be done in TGaxis::PaintAxis() where the “optionTime” is TRUE.