Re: unix epoch data wrapping

[Jonathan T. <jt...@as...>]

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?
  

> 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,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam