Re: Cannot complie internal.c of cvs source (2011-01-02) on Cygwin

[Juhász P. <pet...@gm...>]

On Tue, 2011-01-04 at 04:43 +0900, Tatsuro MATSUOKA wrote:
> Hello
> 
> Thank you for immediate response and treatment.
> 
> Build on the Cygwin with the cvs source dated 2011-01-03 was successful.
> Fine!!
> 

That's good to hear!

> > I've checked in a fix just now. Could you please test it? If it builds
> > successfully, could you test the following command?
> > 
> > print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 
> Cygwin
> gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347398005 347398005.468875 2011/01/03 19:26:45.468875
> 
> MinGW
> gnuplot>  print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347398047 347398047.453125 2011/01/03 19:27:27.453125
> 
> DJGPP 
> gnuplot>  print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347430489 347430489.76 2011/01/04 04:28:09.760000
> 
> Note that the result in DJGPP is different from those in Cygwin and MinGW.
> Perhaps DJGPP uses JST (Japanese Standard Time, UTC+9) and Cygwin and MinGW use UTC.
> 
> I do not know which you would like to implement.
> 

The fact that DJGPP returns a different answer is somewhat worrisome.
Gnuplot uses and assumes UTC more or less consistently. Therefore "time"
should return UTC as well. On a well-behaved platform where the system
clock runs in UTC and there is a sane mechanism in the OS to handle time
zones, gettimeofday() does return UTC, and so does gnuplot's "time".
Apparently, DJGPP is not such a platform, because the underlying system
call uses local time. Perhaps we should fall back to the good old time()
function on DJGPP, or figure out a different implementation if that's
bad as well.

Interestingly, on linux I get something like this:

gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347400672 347400672.289117 2011/01/03 20:11:12.289168

which means that the timer is precise enough to measure the time elapsed
between the consecutive function calls.

Péter Juhász