bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22034: time-utc->date shows bogus zone-dependent leap second


From: Zefram
Subject: bug#22034: time-utc->date shows bogus zone-dependent leap second
Date: Fri, 27 Nov 2015 19:51:46 +0000

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.  Describing the same seconds on input as a date structure
with a non-zero zone offset produces the same wrong output, and requesting
output with a different zone offset changes which second is affected.
The faulty output is always 23:59:60 in the output zone.

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.
However, probing for this side of the problem also runs into the
round-tripping failure that I described in bug#22033.

-zefram





reply via email to

[Prev in Thread] Current Thread [Next in Thread]