Menu
▾
▴
Re: unix epoch data wrapping
|
From: <pl...@pi...> - 2010-03-27 23:54:07
|
On 03/27/10 23:45, Jonathan Thornburg wrote:
> On Sat, 27 Mar 2010, Ethan Merritt quoted from the gnuplot source code:
> # /* In line with the current UNIX98 specification by
> # * The Open Group and major Unix vendors,
> # * two-digit years 69-99 refer to the 20th century, and
> # * values in the range 00-68 refer to the 21st century.
> # */
>
> On Saturday 27 March 2010, 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.
>
> It's not based on the Unix time epoch -- the gnuplot %y-interpretation
> switch is between 31 Dec 1968 and 1 Jan 1969, while the Unix time epoch
> is a year later, on 1 Jan 1970.
>
>
>> Still that's
>> the way it is and it's outside of gnuplot. I'm curious as to whether
>> this works that same on windows which thinks the world was created in
>> 1980, not 1970.
>
> On Sat, 27 Mar 2010, Ethan Merritt wrote:
> # Apparently MSWin (or at least Excel) uses a rule that
> # 00-29 is a 21st century date, while 30-99 is a 20th century date.
> # I have no idea what they are expecting to happen in 2030.
>
>
> If I write the 2-digit year "50", does it mean 1950 or 2050?
> [Let's leave aside the possibility of other centuries.]
> In the original poster's case, I gather that 1950 would have been the
> correct interpretation. But if I were plotting future values of a
> retirement portfolio, 2050 would probably be the better choice.
> Fundamentally, there is *no* *way* for gnuplot to know the "correct"
> choice, so it has to make an *arbitrary* choice (which will be wrong
> a fair number of times).
That is correct , so maybe that defines the need for a way to specify
the correct breakpoint.
As an arbitrary rule the MS choice probably gives the most useful range
(for the foreseeable future) since it allows data back to 1931 - 2030 on
two digit format.
It seems a bit mad that with data all within a 50 year period in the
same century I can't deal with this without 'awk'ward hacking of the
data files.
This isn't a bug as such but a better mechanism could be provided. My
previous comment was that this was a documentation bug , so thanks for
providing a patch to clarify the help.
.
I should be pretty simple to provide a variable to over-ride the
rollover date for this sort of case.
CENTURY_ROLLOVER=1969
This would mimic current behaviour and provide backwards compatability.
Setting such a variable could then cope with any data set that spans
less than 100 years, in the two digit format.
The current functionality can only handle this if all data is pre 1969
or post 1969. This being far from a typical situation it would seem to
be bit restrictive.
Does that seem like a useful solution to a valid short-coming?
Regards. Peter.
>
> IMHO gnuplot's current choice is a reasonable one (it's certainly the
> only one I've ever seen in other software, albeit I've never used
> MS-Excel). So, IMHO this is a feature, not a bug.
>
> But it would be useful to document this feature. Here's a suggested
> patch ('diff -u' format) to gnuplot.doc:
>
> *** gnuplot.doc.orig Sun May 17 22:47:35 2009
> --- gnuplot.doc Sat Mar 27 18:42:43 2010
> ***************
> *** 9687,9696 ****
> --- 9687,9700 ----
> it can still be printed with the "%a", "%A", "%b", or "%B" specifier:
> see `set format` for more details about these and other options for printing
> timedata. (`gnuplot` will determine the proper month and weekday from the
> numerical values.)
>
> + In line with the current UNIX98 specification by The Open Group and major
> + Unix vendors, when reading two-digit years with %y, values 69-99 refer to
> + the 20th century, while values 00-68 refer to the 21st century.
> +
> See also `set xdata` and `Time/date` for more information.
>
> Example:
> set timefmt "%d/%m/%Y\t%H:%M"
> tells `gnuplot` to read date and time separated by tab. (But look closely at
>
>
|
