Re: unix epoch data wrapping

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

On 03/27/10 16:31, Jonathan Thornburg wrote:
> On Sat, 27 Mar 2010, pl...@pi... wrote:
>> I have just tried a quick plot of some historical C14 data and got the
>> the plot split in two.
>>
>> the data format is:
>>
>>     68    5   31  31-May-68  -24.8   560.5    3.9 NZ2206
>>
>> I'm reading it with :
>> set timefmt  "%d-%b-%y"
>>
>>
>> the data goes from 1957 to 1990 but gets parsed incorrectly such that
>> any dates prior to '70 gets plotted as dates upto 2070
>
> The key is your date "31-May-68".  Gnuplot has to guess whether this
> means 31 May 1968 or 31 May 2068... and evidently it guessed wrong.
> What happens if you change the data format to be unambiguous, i.e. a
> date "31-May-1968" with   set timefmt "%d-%b-%Y" .  Does that parse
> correctly?
>

short of editting the whole text file that is not too practical. Well I 
suppose I could start scatching my head trying to make an awk script to 
pre-process the data but....


>
>> This presumably has something to do with unix year zero. However, I
>> don't see why underlying system internals should be exposed to the
>> interpretation of user data.
>>
>>
>> Is this some cunning feature or a bug?
>
> 2-digit years are fundamentally ambiguous, so some (arbitrary) decision
> must be made to resolve that ambiguity.  I'm not sure how gnuplot implements
> this internally, but The X/Open standard documents a function  strptime()
> whose man page on my computer says
> |      %y    the year within the current century.  When a century is not other-
> |            wise specified, values in the range 69-99 refer to years in the
> |            twentieth century (1969 to 1999 inclusive); values in the range
> |            00-68 refer to years in the twenty-first century (2000 to 2068 in-
> |            clusive).  Leading zeros are permitted but not required.
>
> ciao,
>

OK, that is certainly the source of what is happening. That seems a 
pretty arbitrary and dumb way to define behaviour that for no good 
reason is based on the otherwise irrelevant unix year dot. Still that's 
the way it is and it's outside of gnuplot. I'm curious as to whether 
this works that same on windows which thinks the world was created in 
1980, not 1970.

This dependancy on "current century" is a beauty. Any program dependant 
on this behaviour would have gone tits-up in y2k roll-over. No wonder 
they grounded all aircraft !

However, gnuplot's help timefmt tells me:

        Format       Explanation
        %d           day of the month, 1--31
        %m           month of the year, 1--12
        %y           year, 0--99
        %Y           year, 4-digit

This is what I refered to when I hit this issue and it indicated I had 
done the right thing. This is wrong and hence a bug. There is no mention 
of 0-69 this century : 70-99 next century.

I find this behaviour so inherently stupid that maybe gnuplot should be 
coding around it.

This must be a pretty typical situation to hit since the turn of the 
century , is there no better solution than pre-parse all my data files 
with awk?!

Thanks for pointing out the root of the problem .

best,

  Peter.