Re: Leap second bug?

[Greg Troxel]

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Ondrej Zajicek <address@hidden> writes:
>
>> (use-modules (srfi srfi-19))
>> (define (str->date str) (string->date str "~d-~m-~Y"))
>> (define (date->str str) (date->string str "~d-~m-~Y"))
>>
>> (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?
>
> Not sure.  Our leap second table is up-to-date.  Apparently,
> `time-utc->date' honors leap seconds, while `date->time-utc' doesn't.
> In the reference implementation at schemers.org (upon which Guile's is
> based), none of these two honors leap seconds AFAICS.
>
> I'm no expert in that area but I would suggest emailing the SRFI-19
> mailing list [0] for advice.  It seems that most implementations use the
> reference implementation with few modifications, in which case most
> implementations might be affected.  Did you try it with other Scheme
> implementations?

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.  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.  Plus to have a timescale that tracks UT, which is an
astronomical time scale, which is why we have leap seconds.

With UTC, one represents seconds since the epoch in a way which does not
count leap seconds.  With TAI, the count includes all seconds (TAI-UTC 
currently being 33)

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

So, I'd say time-utc->date doing any leap second lookups is a bug.