From: <pl...@pi...> - 2007-08-08 17:01:45
|
On Wed, 08 Aug 2007 17:29:53 +0200, Ethan A Merritt <merritt@u.washington.edu> wrote: > On Wednesday 08 August 2007 02:52, Hans-Bernhard Bröker wrote: >> > This causes gnuplot's conversion from base year 1970 to 2000 to be >> > off by about 20220 seconds, which is about 5 1/2 hours. >> >> We're not, as can be shown rather easily by looking at the relevant >> reference tool's output: >> >> $ date --date='2000-01-01 00:00:00 UTC' +'%s' >> 946684800 > > Yes, but the code that is actually being used in time.c is this: > > /* offset from UNIX epoch (1970) to gnuplot epoch */ > static const long epoch_offset > = (long)((ZERO_YEAR - 1970) * 365.25) * DAY_SEC; > > and ((ZERO_YEAR - 1970) * 365.25) * DAY_SEC > = (2000-1970) * 365.25 * 86400.0 > = 946728000.0 > > which is not the same number. > indeed both uses of 365.25 are wrong. in 2000-1970 the mean was 365.33333333333 due to 7 leap years. I see no sense in talking of mean this should be coded 7*366+23*365 : the correct precise integer value. this agrees with: $ date --date='2000-01-01 00:00:00 UTC' +'%s' 946684800 Any use of this "average" concept should be removed from gnuplot. It will only yield correct results one year in four even if the initial offset is corrected. regards, Peter. |