Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2010-03-28 17:53:28
|
-------- 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. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2010-03-28 22:23:06
|
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? 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. |
|
From: <pl...@pi...> - 2010-03-29 07:40:37
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-29 14:55:04
|
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 |
|
From: <pl...@pi...> - 2010-03-29 17:30:38
|
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. |
