Re: unix epoch data wrapping

[<pl...@pi...>]

On 03/28/10 01:18, Ethan Merritt wrote:
> On Saturday 27 March 2010, Jonathan Thornburg wrote:
>> If I write the 2-digit year "50", does it mean 1950 or 2050?
>>          [Let's leave aside the possibility of other centuries.]
>> In the original poster's case, I gather that 1950 would have been the
>> correct interpretation.  But if I were plotting future values of a
>> retirement portfolio, 2050 would probably be the better choice.
>> Fundamentally, there is no way for gnuplot to know the "correct"
>> choice, so it has to make an arbitrary choice (which will be wrong
>> a fair number of times).
>
> Indeed.
> And if you are plotting a timeline of Roman emperors, "68" really
> does mean 68, the year of Nero's death.
>
> There is no end to this quagmire.  The behaviour of a program may even
> depend on which library version it is linked against. Consider this
> lovely bit from the man page for strptime:
>     The  'y' (year in century) specification is taken to specify a year in
>     the 20th century by libc4 and libc5. It is taken to be a year  in  the
>     range  1950-2049  by  glibc 2.0. It is taken to be a year in 1969-2068
>     since glibc 2.1.
>

Argh , what a mess. Can someone explain the meaning of backwards 
compatibile to gnu.org ?!

In view of the ugly truth would it be better to use , or make available 
, a different way to parse this data rather than relying on the moving 
sand algorithm ?

In order to get stable behaviour this type of data could be read in as a 
string and parsed by gnuplot rather than strptime.

I recall quite a while back you commented this area was a bit hairy , 
I'm starting to see what your were refering to.


> So yes, I'll add a note in the documentation.  But better by far not to
> use two-digit dates.

I agree, but I did not design the data format .  I suppose awk may be 
the short answer , though it would be good to have a more stable 
implementation that would give some insurance against the next arbitrary 
change to glibc et al.

regards.


>
> 	Ethan
>
>