Zefram <zef...@fysh.org> writes:
> time-utc->date seems to think that a leap second occurs at a different
> time in each time zone:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define (tdate d) (write (list (date->string d "~4")
> (date->string (time-utc->date (date->time-utc d) 3600) "~4"))) (newline))
> scheme@(guile-user)> (tdate (make-date 0 59 59 22 30 6 2012 0))
> ("2012-06-30T22:59:59Z" "2012-06-30T23:59:59+0100")
> scheme@(guile-user)> (tdate (make-date 0 0 0 23 30 6 2012 0))
> ("2012-06-30T23:00:00Z" "2012-06-30T23:59:60+0100")
> scheme@(guile-user)> (tdate (make-date 0 1 0 23 30 6 2012 0))
> ("2012-06-30T23:00:01Z" "2012-07-01T00:00:01+0100")
>
> These are three consecutive seconds that occur an hour before a genuine
> leap second (at 23:59:60Z). Observe that time-utc->date, applied to the
> middle second, describes it as a leap second happening at 23:59:60+01:00,
> which is bogus. [...]
This is fixed by commit 5106377a3460e1e35daf14ea6edbe80426347155 on the
stable-2.2 branch.
> Matching up with this, the actual leap second is never correctly described
> with a non-zero zone offset. It should be, for example, 00:59:60+01:00.
If I understand correctly, 'time-utc->date' should never return a date
object with 60 in the seconds field, because those extra seconds have no
representation in time-utc. They only have representations in time-tai
and time-monotonic.
Anyway, thanks very much for these reports! I'm closing this bug now,
but feel free to reopen if you think there are still issues to resolve.
Mark
