Re: 30-year time offset reading nonuniform matrix %s input

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

On Wed, 2013-04-03 at 12:36 -0700, Ethan Merritt wrote:
> On Wednesday, April 03, 2013 11:38:27 am Tait wrote:
> > 
> > Consider these two examples. First:
> >   reset
> >   set datafile separator ","
> >   set xdata time
> >   set timefmt "%s"
> >   set format x "%Y-%m-%d %H:%M:%S"
> >   set view 47,54
> >   splot '-' using 1:2:3 with impulses
> >   1364987000,50,19
> >   1364987000,100,1
> >   1364987000,150,0
> > 
> >   1364990600,50,15
> >   1364990600,100,4
> >   1364990600,150,1
> > 
> >   1364942000,50,9
> >   1364942000,100,5
> >   1364942000,150,7
> > 
> >   1365001400,50,11
> >   1365001400,100,7
> >   1365001400,150,2
> >   e
> > 
> > ... and second:
> >   reset
> >   set datafile separator ","
> >   set xdata time
> >   set timefmt "%s"
> >   set format x "%Y-%m-%d %H:%M:%S"
> >   set view 47,54
> >   splot '-' nonuniform matrix using 2:1:3 with impulses
> >   0,50.00,100.00,150.00
> >   1364987000,19,1,0
> >   1364990600,15,4,1
> >   1364942000,9,5,7
> >   1365001400,11,7,2
> >   e
> >   e
> > 
> > (I don't understand why the second example requires two 'e's either,
> > but I digress...)
> > 
> > In the first case, the year is correctly set to 2013. In the second,
> > it is displayed as 2043. This seems to be a mistake in the nonuniform
> > matrix time input?
> 
> Does anyone know why, way back in the mists of time, gnuplot decided to 
> define its own epoch boundary as 1-jan-2000 rather than use the conventional
> unix epoch boundary 1-jan-1970? 
>   
> Did it have something to do with fitting an integer number of seconds 
> in a 32-bit, or even 16-bit, integer? 
> 
> How many things would break if we did away with this 30 year disagreement?
> 
> 	Ethan
> 
> 

Currently this disagreement manifests itself even in the user interface:
the meaning of "%s" is different, depending on whether it was used as an
input or output spec.

Doing away with it might break a few scripts that depend on the epoch
being 2000.0, but on the plus side it would make everything clearer and
more consistent - both the internal implementation and the user
documentation, not to mention that it would also be consistent with the
rest of the (Unix) world.

I might add that 4.6.0 would have been a good place to make this change.

Peter