Re: Fwd: Re: unix epoch data wrapping

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

On 03/29/10 00:22, sfeam (Ethan Merritt) wrote:
> On Sunday 28 March 2010, pl...@pi... wrote:
>
>
>> what I asked for was for the software to behave as indicated in the
>> doc : help for timefmt %y.
>> There is no mention of this idiocy in help timefmt.
>>
>> That is a gnuplot shortcoming that has just been rectified thanks to my
>> pointing it out and someone else providing a patch.
>>
>> "Thanks ?". Don't mention it , just carry on with the rant and insults.
>> It's what you do so well.
>>
>> Software should not expect humans to know the subtle , unstable
>> meanderings of an underlying library's internals and adapt their
>> behaviour to the illogical software.
>
> Please, both of you, let's keep the discussion civil.
> Sniping at each other will not help, although bemoaning the sorry
> state of software design in general is a time-honored tradition.
>
> To the extent that there is any standard, the code follows it.
> As is often the case, we may argue that the standard is crazy, but
> where is there a better option?

I'm not sure this can in anyway be regarded as a "standard". Primarily 
because it keeps changing. There also seem to a number of choices about 
doing this all of which seem pretty arbitrary choices.


>
> It's 50 years too late to avoid the original mistake of encoding dates
> electronically as 2-digit characters.  And it's probably 50 years too
> early to expect software to be intelligent enough to figure out on its
> own that a particular data file refers specifically to dates in the
> 20th century as opposed to the current or some other century.
>
> On the bright side, gnuplot's string handling should now be good
> enough to work around the problem once you are aware that your particular
> data files will trigger it.  If that isn't the case, then a bug report
> with an example of the difficulty would be appreciated.
>
I don't recall you commenting on my suggestion of providing a rollover 
date to gnuplot.

This would cover all bases. If someone wants to adopt MS excel 
convention they feed in 2039. If they want humanly logical results they 
give it 2000. If they were born in 1969 they can use 1969 ;)

Though I feel 2000 should be the logical default behaviour,  I'm pretty 
sure you'd want to ensure this is backwards compatible. Since current 
behaviour seems to depend on what version of certain libs is installed , 
it seems not supplying a value has to default to the current anarchic 
situation in the hope that this will prompt the user to refer to the doc 
when the plot comes out arse about face.

The doc should then have some comment about why it happens and document 
the variable usage.

To avoid having to code all the possible date/time options currently in 
there maybe gnuplot could call strptime internally with some test dates 
to sniff it's rollover behaviour then adjust the data read in. The sniff 
should be as trivial as the adjustment to code.

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.

regards. Peter.