Fwd: Re: unix epoch data wrapping

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

-------- Original Message --------
Subject: Re: unix epoch data wrapping
Date: Sun, 28 Mar 2010 18:52:15 +0200
From: pl...@pi...
To: Hans-Bernhard Bröker <HBB...@t-...>

On 03/28/10 12:58, Hans-Bernhard Bröker wrote:
> pl...@pi... wrote:
>
>
>> 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.
>
> What you're still not getting is that the arbitrariness in gnuplot is a
> _necessary_consequence_ of the equally arbitrary assumption needlessly
> built into your data format. One might have thought that all the fuss
> and borderline panic about the Y2K issue might have taught people once
> and for all that it's utterly foolish to save digits on the year number
> for the price of confusions like this. Well, hope survives in the face
> of contrary evidence...

There is no arbitrary assumption in the data. It all relates to 20th c.
, it would be "needless" to put 19 in every data line of every data file.

If the data does not span y2k it is not "utterly foolish" but normal.

>
>> This dependancy on "current century" is a beauty. Any program
>> dependant on this behaviour would have gone tits-up in y2k roll-over.
>
> No program being forced by _you_, the user, to deal with 2-digit year
> numbers has the slightest chance to _avoid_ falling over on some
> occasions, be they Y2K, Y2K38 or the Unix epoch.

If the data spanned y2k that would be a valid comment. I see no reason a
scientist would start to wonder if someone would want to use a plotting
tool that  would be using a libc that for some unfathomable reason
decides to parse input on based on a relative rather than absolute
condition like "current century" and use this to switch the
interpretation of data on an equally unfathomable date , apparently
1969. Somebody's birthday maybe ? WTF?

>
> In a nutshell, you got what you asked for.
>
No,  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.

>> I find this behaviour so inherently stupid that maybe gnuplot should
>> be coding around it.
>
> Pardon the French, but the only truly stupid behaviour I can see here is
> your (or whoever's) choice of data format. 2-digit years are totally,
> inexcusably stupid.

All _you_ can see indeed, since you have not followed the thread. I said
this was not my data , I also said it was historical data.

It was collected by scientists with the incredible , inexcusable
stupidity to be working and  living in the 20th century. The data spans
1945- 1990.

In this context two digits seems a sensible rather than stupid choice.
In fact is was very common practice in life before y2k.

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.

>
>> This must be a pretty typical situation to hit since the turn of the
>> century
>
> No. The typical reaction to the Y2K was for people to (finally) come to
> their senses and switch to 4-digit years. I.e. the typical situation
> _was_ that for data to be in 2-digit year format. Since the turn of the
> century, that's no longer the case.
>
>  > , is there no better solution than pre-parse all my data files
>> with awk?!
>
> The better solution is not to write data files in such a silly format in
> the first place.
>
>

The stupidity does not lie in gnuplot , it is in glibc apparently. It
would be useful if gnuplot worked around problem rather than propagating
it and passing the buck when issues crop up.

I suggested a method for providing a stable solution to this sort of
case by providing a variable to gnuplot to define the roll-over year
rather than propagating the inherent unstable situation in the
underlying libs.

For the sake of backwards compat, this should default to the current
behaviour although y2k would be the logical human default for the rollover.

At least if such a feature was available and documented , anyone hitting
such a problem and consulting the help topic would instantly find the
cause and the solution.

So if we can put the abuse to one side and consider the merits of a
solution which seems clean and painless to implement , that would
probably be more productive.


best regards, Peter.