Re: Fwd: Re: unix epoch data wrapping

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

On 03/29/10 16:49, Ethan Merritt wrote:
> On Monday 29 March 2010, pl...@pi... wrote:
>
>> If gnuplot could work around the instability in the libraries it uses,
>> this would seem preferable to burdening users with playing around with
>> specific string handling. I'd regard that as a workaround rather than a
>> solution.
>
> You have missed, or misunderstood, an earlier posting.
> The gnuplot time code does not depend on an external library.
> I posted the code (from time.c) that it uses to interpret the %y format.
> The gnuplot code was written last century, and adheres to the closest
> thing to a "standard" that was available at the time.  It has not
> changed since then, which one can view as backwards consistency or
> continued foolishness as the case may be.
>
> I pointed out the shifting sands of time-handling in libc not to
> explain gnuplot's behaviour, but just as a additional bit of evidence
> that the whole area is frought with inconsistency.
>
> 	Ethan
>

OK , apologies, I apparently was not paying enough attention. I did see 
the post.

Tait has just come up with a very simple work around. Reading data as %Y 
interprets data like 68 AD but produces labels like 14/05/59 which looks 
fine in the context. I could also add 1900 to this value in the plot 
command. That does what I need.

At this point only data spanning a century boundary would present 
problems. It may be argued that if such data is not explicit , it should 
be.

I would still maintain that the current somewhat arbitrary behaviour is 
flawed and it would be better if my rollover variable solution provided 
a way to define this without having to resort to Tait's workaround , 
which presumably will never be documented.

I don't have time to dig into the source and submit a patch so I'll just 
have to settle for contribution a possible solution and having got some 
way to improving the %y documentation.

Thanks to those who have helped.

Peter.