GNU bug report logs - #21911
TAI-to-UTC conversion leaps at wrong time

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Zefram <zefram <at> fysh.org>
Subject: bug#21911: closed (Re: bug#21911: TAI-to-UTC conversion leaps at
 wrong time)
Date: Sat, 20 Oct 2018 21:32:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#21911: TAI-to-UTC conversion leaps at wrong time

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 21911 <at> debbugs.gnu.org.

-- 
21911: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21911
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mark H Weaver <mhw <at> netris.org>
To: Zefram <zefram <at> fysh.org>
Cc: 21911-done <at> debbugs.gnu.org
Subject: Re: bug#21911: TAI-to-UTC conversion leaps at wrong time
Date: Sat, 20 Oct 2018 17:30:42 -0400

Zefram <zefram <at> fysh.org> writes:

> Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date,
> in the minutes around the leap second in 2012:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (for-each (lambda (d) (write (list d
> (date->string (time-tai->date (add-duration (julian-day->time-tai
> 2456109) (make-time time-duration 0 d)) 0) "~4"))) (newline)) (list
> 43000 43160 43164 43165 43166 43167 43199 43200 43201 43202))
> (43000 "2012-06-30T23:56:40Z")
> (43160 "2012-06-30T23:59:20Z")
> (43164 "2012-06-30T23:59:24Z")
> (43165 "2012-06-30T23:59:25Z")
> (43166 "2012-06-30T23:59:25Z")
> (43167 "2012-06-30T23:59:26Z")
> (43199 "2012-06-30T23:59:58Z")
> (43200 "2012-06-30T23:59:59Z")
> (43201 "2012-06-30T23:59:60Z")
> (43202 "2012-07-01T00:00:01Z")

This is fixed by commit 5106377a3460e1e35daf14ea6edbe80426347155 on the
stable-2.2 branch.  I'm closing this bug now, but feel free to reopen if
appropriate.

    Thanks!
      Mark

[Message part 3 (message/rfc822, inline)]

From: Zefram <zefram <at> fysh.org>
To: bug-guile <at> gnu.org
Subject: TAI-to-UTC conversion leaps at wrong time
Date: Fri, 13 Nov 2015 16:19:58 +0000

Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date,
in the minutes around the leap second in 2012:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (for-each (lambda (d) (write (list d (date->string (time-tai->date (add-duration (julian-day->time-tai 2456109) (make-time time-duration 0 d)) 0) "~4"))) (newline)) (list 43000 43160 43164 43165 43166 43167 43199 43200 43201 43202))
(43000 "2012-06-30T23:56:40Z")
(43160 "2012-06-30T23:59:20Z")
(43164 "2012-06-30T23:59:24Z")
(43165 "2012-06-30T23:59:25Z")
(43166 "2012-06-30T23:59:25Z")
(43167 "2012-06-30T23:59:26Z")
(43199 "2012-06-30T23:59:58Z")
(43200 "2012-06-30T23:59:59Z")
(43201 "2012-06-30T23:59:60Z")
(43202 "2012-07-01T00:00:01Z")

The julian-day->time-tai conversion is correct (the JD refers to
2012-06-30T12:00:00 UTC, which is 2012-06-30T12:00:34 TAI), and the
duration addition works in a perfectly regular manner in TAI space.
All the interesting stuff happens in the TAI-to-UTC conversion, between
the time-tai structure and the date structure.  The same thing happens
if the conversion is performed by separate time-tai->time-utc and
time-utc->date calls.  The date->string part is correct and uninteresting.

The conversion is initially correct, minutes before midnight, but a
discontinuity is seen 35 seconds before midnight.  Outputs from then up
to one second after midnight are one second slow.  At one second after
midnight it recovers.  Because 35 seconds happens to be the TAI-UTC
difference prevailing immediately after this leap second, I suspect that
this is down to a time_t value (as used in the time-utc structure) for
the moment of the leap being misinterpreted as a time-tai seconds value.

The UTC-to-TAI conversion is in better shape.  As a result,
time-tai->time-utc and time-utc->time-tai are not inverses during the
35 second erroneous period.  Round-tripping through the two conversions
produces an output not matching the input.

-zefram

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.