The following commands result in a nonsensical plot with the current CVS version (not tested yet with 4.4.x):
set xdata time
set timefmt x "%s"
set format x "%Y/%m/%d %H:%m"
set xtics rotate
plot '-' using (timecolumn(1)):1
These unix timestamps refer to today, but the plot shows 1970/01/01. There is an additional warning:
empty x range [-9.45734e+08:-9.45734e+08], adjusting to [-9.55192e+08:-9.36277e+08]
Gnuplot's date/time processing is hideously complicated, and I don't yet know where it goes wrong in this case.
I do know however, that the section responsible for the %s format string in time.c's gstrptime() function is incorrect.
/\* offset from UNIX epoch \(1970\) to gnuplot epoch \*/ static const long epoch\_offset = \(long\)\(\(ZERO\_YEAR - 1970\) \* 365.25\) \* DAY\_SEC; when = strtod \(s, &s\) - epoch\_offset;
This formula is off by half a day. It uses an average year length of 365.25 days, which corresponds to one leap day per 4 years. However, there are only 7 leap days in the 30 years between 1970 and 2000. The section above should be replaced with
when = strtod \(s, &s\) - SEC\_OFFS\_SYS;
By the way, what was the original reason behind choosing 2000 as the epoch? Does this choice have any advantage over the traditional 1970?
If the internal epoch were the same as the system's, there would be no need for this SEC_OFFS_SYS business, and we could also do away with the annoying inconsistency in the behavior of the "%s" format string. As of now, on input it means the number of seconds since 1970, but on output it means the number of seconds since 2000.
Log in to post a comment.