[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Leap second bug?
Re: Leap second bug?
Mon, 9 Jun 2008 13:18:26 -0400
> From: Greg Troxel <address@hidden>
> It seems very odd for time-utc->date to pay attention to leap seconds.
> I would only expect leap seconds to come into play when converting
> between UTC and TAI.
Procedure time-utc->date resents the anthropomorphism.
The author of that procedure probably paid some attention,
but not enough, otherwise the answer would be right.
> The whole point of UTC is to have a timescale with the same number
> of seconds per day so that one can ignore the mess of leap seconds.
I think this is provably false. If anyone wants to argue, I will
look up original references, but for now I will just quote something
I wrote a few years ago, after spending much more time on this
issue than all the leap seconds in the history of the universe.
> UTC can not be expressed as a single number (in any units), but must
> be expressed as a day (either Julian Day or Gregorian Calendar
> Date), together with a time within that day (expressed as hours,
> minutes, and seconds, as total number of seconds, or as a fraction
> of a day). This is because the days are not all the same length.
> Most of them are $86\,400$ seconds (exactly), but when a leap second
> is inserted the day is $86\,401$ seconds (exactly).
> With UTC, one represents seconds since the epoch in a way which does
> not count leap seconds.
UTC is _not_ expressed in seconds.
If it were, it would be messed up whenever a second
passed without incrementing the count.
> With TAI, the count includes all seconds
> (TAI-UTC currently being 33)
This true (to within a second) and explains why
we don't use TIA much. It's too hard to figure out
the date, which the boss cares about.
> (I would say that a time difference of two UTC times should return
> the arithmetic difference of the two seconds-since-epoch values, and
> of two TAI times the same thing, but the TAI ones will have leap
> seconds. This is not clear in the srfi-19 text.)
The srfi says the input to time-utc->date is a of type
time-utc. I don't find a definition of that in the srfi.
(There is a symbol with that name, but no type.)
It probably means a time object with component time-type
set to the symbol time-utc. This is bad, because
a time object is a count of seconds, and UTC is not.
> So, I'd say time-utc->date doing any leap second lookups is a bug.
I don't know what a procedure should do if it is
based upon a spec that violates international standards.
> > Ondrej Zajicek <address@hidden> writes:
> >> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
> >> -> "31-12-2005"
> >> Is is a bug in leap second handling or is it a expected behavior?
I am open to argument on other things, but I am sure that
if this is expected behavior, it is bug in someone's expectations.