Re: Leap second bug?

[Keith Wright]

> 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.

  -- Keith