[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > Ondrej Zajicek <[EMAIL PROTECTED]> 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.
