GNU logs - #26632, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#26632: TAI<->UTC conversion botches 1961 to 1971
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 24 Apr 2017 01:03:02 +0000
Resent-Message-ID: <handler.26632.B.149299577724497 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 26632 <at> debbugs.gnu.org
Date: Mon, 24 Apr 2017 02:02:18 +0100
From: Zefram <zefram@HIDDEN>
Message-ID: <20170424010218.GL6765@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

The SRFI-19 library gets TAI<->UTC conversions badly wrong in the years
1961 to 1971 (inclusive).

This has to be examined somewhat indirectly, because SRFI-19 doesn't offer
any way to display a TAI time in its conventional form as a date-like
structure, nor to input a TAI time from such a structure.  SRFI-19's
date structure, as implemented, is always interpreted according to UTC.
The only operations supported on TAI time structures are conversions to
and from the various forms of UTC, conversions to and from the less-useful
`monotonic' time, and arithmetic operations.  Thus the erroneous TAI<->UTC
conversions only come out through arithmetic operations in TAI space.
One must also be careful to avoid unrelated bugs such as bug#21911.

First I'll consider an ordinary day in 1967:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (time-difference
... (time-utc->time-tai (date->time-utc (make-date 0 0 0 0 15 3 1967 0)))
... (time-utc->time-tai (date->time-utc (make-date 0 0 0 0 14 3 1967 0))))
$1 = #<time type: time-duration nanosecond: 0 second: 86400>

This takes the start and end of 1967-03-14, as judged by UTC, converts
both of these times to TAI, and asks for the duration of that TAI
interval.  It's asking how many TAI seconds long that UTC day was.
As described in <http://maia.usno.navy.mil/ser7/tai-utc.dat>, there
was no UTC leap on that day, but throughout 1967 UTC had a frequency
offset from TAI such that each UTC second lasted exactly 1.00000003 TAI
seconds.  The correct answer to the above question is therefore exactly
86400.002592 s.  The answer shown above, of 86400.000000 s, is incorrect.

If time-tai->time-utc is applied to the times in the above example,
it accurately inverts what time-utc->time-tai did.  It is good that the
conversions are mutually consistent, but in this case it means they are
both wrong.

Second, I'll consider a less ordinary day:

scheme@(guile-user)> (time-difference
... (time-utc->time-tai (date->time-utc (make-date 0 0 0 12 1 2 1968 0)))
... (time-utc->time-tai (date->time-utc (make-date 0 0 0 12 31 1 1968 0))))
$2 = #<time type: time-duration nanosecond: 0 second: 86400>

This time the period considered is from noon 1968-01-31 to noon
1968-02-01.  The same frequency offset described above applies throughout
this period.  The additional complication here is that at the end of
1968-01-31 there was a leap of -0.1 (TAI) seconds.  The true duration of
this day is therefore exactly 86399.902592 s.  The answer shown above,
of 86400.000000 s, is incorrect in two ways, accounting for neither the
frequency offset nor the leap.

Once again, time-tai->time-utc accurately inverts the incorrect
time-utc->time-tai.  The failure to handle UTC's leaps in this era is
not specific to the relatively unusual negative leaps: it's equally
clueless about the positive leaps.

The full extent of the conversion errors, integrated across the entire
"rubber seconds" era from 1961-01-01 to 1972-01-01, is a little over
8.5 seconds of TAI.

This bug influences bug#26164, regarding time arithmetic in UTC.  If one
were to ignore the rubber seconds era, an obvious way to correct UTC
time arithmetic would be to convert to TAI and the arithmetic there.
That handles UTC leaps correctly.  But with rubber seconds it would
still be wrong.  In the rubber seconds era the number of UTC seconds in
an interval differs from the number of TAI seconds.

-zefram

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Zefram <zefram@HIDDEN>
Subject: bug#26632: Acknowledgement (TAI<->UTC conversion botches 1961 to
 1971)
Message-ID: <handler.26632.B.149299577724497.ack <at> debbugs.gnu.org>
References: <20170424010218.GL6765@HIDDEN>
X-Gnu-PR-Message: ack 26632
X-Gnu-PR-Package: guile
Reply-To: 26632 <at> debbugs.gnu.org
Date: Mon, 24 Apr 2017 01:03:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 26632 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
26632: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D26632
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#26632: TAI<->UTC conversion botches 1961 to 1971
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 24 Oct 2018 05:58:02 +0000
Resent-Message-ID: <handler.26632.B26632.154036067820064 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Zefram <zefram@HIDDEN>
Cc: 26632 <at> debbugs.gnu.org
From: Mark H Weaver <mhw@HIDDEN>
References: <20170424010218.GL6765@HIDDEN>
Date: Wed, 24 Oct 2018 01:57:33 -0400
In-Reply-To: <20170424010218.GL6765@HIDDEN> (Zefram's message of "Mon, 24
 Apr 2017 02:02:18 +0100")
Message-ID: <87zhv3yjhu.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain

Hi Zefram,

Zefram <zefram@HIDDEN> writes:
> The SRFI-19 library gets TAI<->UTC conversions badly wrong in the years
> 1961 to 1971 (inclusive).

Indeed.

> This has to be examined somewhat indirectly, because SRFI-19 doesn't offer
> any way to display a TAI time in its conventional form as a date-like
> structure, nor to input a TAI time from such a structure.

FWIW, here are two procedures I hacked up to support TAI dates:

--8<---------------cut here---------------start------------->8---
(define (time-tai->date-tai t . tz-offset)
  (apply time-tai->date
         (time-utc->time-tai! (make-time time-utc
                                         (time-nanosecond t)
                                         (time-second t)))
         tz-offset))

(define (date-tai->time-tai d)
  (let ((t (time-tai->time-utc (date->time-tai d))))
    (set-time-type! t time-tai)
    t))
--8<---------------cut here---------------end--------------->8---

> SRFI-19's date structure, as implemented, is always interpreted
> according to UTC.

Indeed, I discovered this as well, and found it surprising.  The text of
SRFI-19 fails to mention it, but the reference implementation makes it
quite clear.

> First I'll consider an ordinary day in 1967:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (time-difference
> ... (time-utc->time-tai (date->time-utc (make-date 0 0 0 0 15 3 1967 0)))
> ... (time-utc->time-tai (date->time-utc (make-date 0 0 0 0 14 3 1967 0))))
> $1 = #<time type: time-duration nanosecond: 0 second: 86400>
>
> This takes the start and end of 1967-03-14, as judged by UTC, converts
> both of these times to TAI, and asks for the duration of that TAI
> interval.  It's asking how many TAI seconds long that UTC day was.
> As described in <http://maia.usno.navy.mil/ser7/tai-utc.dat>, there
> was no UTC leap on that day, but throughout 1967 UTC had a frequency
> offset from TAI such that each UTC second lasted exactly 1.00000003 TAI
> seconds.  The correct answer to the above question is therefore exactly
> 86400.002592 s.  The answer shown above, of 86400.000000 s, is incorrect.
>
> If time-tai->time-utc is applied to the times in the above example,
> it accurately inverts what time-utc->time-tai did.  It is good that the
> conversions are mutually consistent, but in this case it means they are
> both wrong.
>
> Second, I'll consider a less ordinary day:
>
> scheme@(guile-user)> (time-difference
> ... (time-utc->time-tai (date->time-utc (make-date 0 0 0 12 1 2 1968 0)))
> ... (time-utc->time-tai (date->time-utc (make-date 0 0 0 12 31 1 1968 0))))
> $2 = #<time type: time-duration nanosecond: 0 second: 86400>
>
> This time the period considered is from noon 1968-01-31 to noon
> 1968-02-01.  The same frequency offset described above applies throughout
> this period.  The additional complication here is that at the end of
> 1968-01-31 there was a leap of -0.1 (TAI) seconds.  The true duration of
> this day is therefore exactly 86399.902592 s.  The answer shown above,
> of 86400.000000 s, is incorrect in two ways, accounting for neither the
> frequency offset nor the leap.

I've attached two patches to fix this bug.  The first lays the
groundwork by adding support for non-integer TAI-UTC deltas.  The second
patch adds the TAI-UTC tables for 1961-1971 and uses them to implement
TAI<->UTC conversions over that time range with nanosecond accuracy.

Although the code is now written, I'm unsure whether we should add it to
Guile.  I'm vaguely concerned about violating widely-held assumptions,
e.g. that UTC runs at the same rate as TAI (except when leap seconds are
introduced), which might cause some code on top of Guile to misbehave if
the system clock is set pre-1972, although admittedly such a scenario
seems unlikely.

I'm curious to hear opinions on this.

Anyway, here are the patches.

      Mark



--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-SRFI-19-TAI-UTC-conversions-support-non-integer-delt.patch
Content-Description: [PATCH 1/2] SRFI-19: TAI<->UTC conversions support
 non-integer deltas

From 3a67fbfd441b39630ff3c3201d2a731b51b1a8ee Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@HIDDEN>
Date: Tue, 23 Oct 2018 00:39:30 -0400
Subject: [PATCH 1/2] SRFI-19: TAI<->UTC conversions support non-integer
 deltas.

Previously, 'utc->tai' and 'tai->utc' were unary procedures and returned
a second value, mapping seconds to seconds, based on the assumption that
the nanoseconds field would never be changed by these maps.  To support
non-integer values of TAI-UTC, here we change 'utc->tai' and 'tai->utc'
to accept two arguments and return two values: nanoseconds and seconds.

* module/srfi/srfi-19 (utc->tai, tai->utc): Add an additional 'ns'
argument, and return it as an additional value.
(current-time-tai, priv:time-tai->time-utc!, priv:time-utc->time-tai!)
(time-tai->julian-day, time-monotonic->julian-day): Adapt accordingly.
---
 module/srfi/srfi-19.scm | 56 +++++++++++++++++++++++------------------
 1 file changed, 31 insertions(+), 25 deletions(-)

diff --git a/module/srfi/srfi-19.scm b/module/srfi/srfi-19.scm
index 46de91a7e..f653b1bc3 100644
--- a/module/srfi/srfi-19.scm
+++ b/module/srfi/srfi-19.scm
@@ -237,21 +237,21 @@
   (set! leap-second-table (read-tai-utc-data filename)))
 
 
-(define (utc->tai utc-seconds)
+(define (utc->tai ns utc-seconds)
   (let loop ((table leap-second-table))
     (cond ((null? table)
-           utc-seconds)
+           (values ns utc-seconds))
           ((>= utc-seconds (caar table))
-           (+ utc-seconds (cdar table)))
+           (values ns (+ utc-seconds (cdar table))))
           (else
            (loop (cdr table))))))
 
-(define (tai->utc tai-seconds)
+(define (tai->utc ns tai-seconds)
   (let loop ((table leap-second-table))
     (cond ((null? table)
-           tai-seconds)
+           (values ns tai-seconds))
           ((>= tai-seconds (+ (caar table) (cdar table)))
-           (- tai-seconds (cdar table)))
+           (values ns (- tai-seconds (cdar table))))
           (else
            (loop (cdr table))))))
 
@@ -309,9 +309,8 @@
   (let* ((tod (gettimeofday))
          (sec (car tod))
          (usec (cdr tod)))
-    (make-time time-tai
-               (* usec 1000)
-               (utc->tai sec))))
+    (receive (ns s) (utc->tai (* usec 1000) sec)
+      (make-time time-tai ns s))))
 
 ;;(define (current-time-ms-time time-type proc)
 ;;  (let ((current-ms (proc)))
@@ -460,10 +459,12 @@
 (define (priv:time-tai->time-utc! time-in time-out caller)
   (if (not (eq? (time-type time-in) time-tai))
       (time-error caller 'incompatible-time-types time-in))
-  (set-time-type! time-out time-utc)
-  (set-time-nanosecond! time-out (time-nanosecond time-in))
-  (set-time-second!     time-out (tai->utc (time-second time-in)))
-  time-out)
+  (receive (ns s) (tai->utc (time-nanosecond time-in)
+                            (time-second time-in))
+    (set-time-type! time-out time-utc)
+    (set-time-nanosecond! time-out ns)
+    (set-time-second!     time-out s)
+    time-out))
 
 (define (time-tai->time-utc time-in)
   (priv:time-tai->time-utc! time-in (make-time-unnormalized #f #f #f) 'time-tai->time-utc))
@@ -475,10 +476,13 @@
 (define (priv:time-utc->time-tai! time-in time-out caller)
   (if (not (eq? (time-type time-in) time-utc))
       (time-error caller 'incompatible-time-types time-in))
-  (set-time-type! time-out time-tai)
-  (set-time-nanosecond! time-out (time-nanosecond time-in))
-  (set-time-second!     time-out (utc->tai (time-second time-in)))
-  time-out)
+  (receive (ns s)
+      (utc->tai (time-nanosecond time-in)
+                (time-second time-in))
+    (set-time-type! time-out time-tai)
+    (set-time-nanosecond! time-out ns)
+    (set-time-second!     time-out s)
+    time-out))
 
 (define (time-utc->time-tai time-in)
   (priv:time-utc->time-tai! time-in (make-time-unnormalized #f #f #f) 'time-utc->time-tai))
@@ -807,10 +811,11 @@
 (define (time-tai->julian-day time)
   (if (not (eq? (time-type time) time-tai))
       (time-error 'time-tai->julian-day 'incompatible-time-types  time))
-  (+ (/ (+ (tai->utc (time-second time))
-           (/ (time-nanosecond time) nano))
-        sid)
-     tai-epoch-in-jd))
+  (receive (ns s) (tai->utc (time-nanosecond time)
+                            (time-second time))
+    (+ (/ (+ s (/ ns nano))
+          sid)
+       tai-epoch-in-jd)))
 
 (define (time-tai->modified-julian-day time)
   (- (time-tai->julian-day time)
@@ -820,10 +825,11 @@
 (define (time-monotonic->julian-day time)
   (if (not (eq? (time-type time) time-monotonic))
       (time-error 'time-monotonic->julian-day 'incompatible-time-types  time))
-  (+ (/ (+ (tai->utc (time-second time))
-           (/ (time-nanosecond time) nano))
-        sid)
-     tai-epoch-in-jd))
+  (receive (ns s) (tai->utc (time-nanosecond time)
+                            (time-second time))
+    (+ (/ (+ s (/ ns nano))
+          sid)
+       tai-epoch-in-jd)))
 
 (define (time-monotonic->modified-julian-day time)
   (- (time-monotonic->julian-day time)
-- 
2.19.1


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0002-SRFI-19-Implement-correct-TAI-UTC-conversions-for-19.patch
Content-Description: [PATCH 2/2] SRFI-19: Implement correct TAI<->UTC
 conversions for 1961-1971

From adfcb5ee624d457a8dae33e8e122cbff6d4a1428 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@HIDDEN>
Date: Tue, 23 Oct 2018 00:42:12 -0400
Subject: [PATCH 2/2] SRFI-19: Implement correct TAI<->UTC conversions for
 1961-1971.

* module/srfi/srfi-19.scm (tai-utc-1961-1971-table): New variable.
(pre-1972-utc->tai, pre-1972-tai->utc): New procedures.
(utc->tai, tai->utc): Use the new procedures.
---
 module/srfi/srfi-19.scm | 58 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/module/srfi/srfi-19.scm b/module/srfi/srfi-19.scm
index f653b1bc3..d4afa1931 100644
--- a/module/srfi/srfi-19.scm
+++ b/module/srfi/srfi-19.scm
@@ -240,7 +240,7 @@
 (define (utc->tai ns utc-seconds)
   (let loop ((table leap-second-table))
     (cond ((null? table)
-           (values ns utc-seconds))
+           (pre-1972-utc->tai ns utc-seconds))
           ((>= utc-seconds (caar table))
            (values ns (+ utc-seconds (cdar table))))
           (else
@@ -249,13 +249,67 @@
 (define (tai->utc ns tai-seconds)
   (let loop ((table leap-second-table))
     (cond ((null? table)
-           (values ns tai-seconds))
+           (pre-1972-tai->utc ns tai-seconds))
           ((>= tai-seconds (+ (caar table) (cdar table)))
            (values ns (- tai-seconds (cdar table))))
           (else
            (loop (cdr table))))))
 
 
+(define tai-utc-1961-1971-table
+  ;;      UTC start       delta@start  slope
+  ;;        (ns)             (ns)      (ns/s)
+  '(( -60480000000000000  6185682000    30)
+    (-126230400000000000  4313170000    30)
+    (-136771200000000000  4155058000    15)
+    (-142128000000000000  3974706000    15)
+    (-152668800000000000  3716594000    15)
+    (-157766400000000000  3540130000    15)
+    (-168307200000000000  3282018000    15)
+    (-181526400000000000  2983730000    15)
+    (-189388800000000000  2765794000    15)
+    (-194659200000000000  2697278800    13)
+    (-252460800000000000  1845858000    13)
+    (-265680000000000000  1647570000    15)
+    (-283996800000000000  1422818000    15)))
+
+(define (pre-1972-utc->tai ns utc-seconds)
+  (let ((utc-ns (+ ns (* nano utc-seconds))))
+    (let loop ((table tai-utc-1961-1971-table))
+      (cond ((null? table)
+             (values ns utc-seconds))
+            ((>= utc-ns (caar table))
+             (apply (lambda (utc-start delta@start slope)
+                      (let ((tai-ns (+ utc-ns
+                                       delta@start
+                                       (round-quotient (* slope (- utc-ns
+                                                                   utc-start))
+                                                       nano))))
+                        (values (truncate-remainder tai-ns nano)
+                                (truncate-quotient tai-ns nano))))
+                    (car table)))
+            (else
+             (loop (cdr table)))))))
+
+(define (pre-1972-tai->utc ns tai-seconds)
+  (let ((tai-ns (+ ns (* nano tai-seconds))))
+    (let loop ((table tai-utc-1961-1971-table))
+      (cond ((null? table)
+             (values ns tai-seconds))
+            ((>= tai-ns (+ (caar table) (cadar table)))
+             (apply (lambda (utc-start delta@start slope)
+                      (let ((utc-ns (+ utc-start
+                                       (round-quotient (* nano (- tai-ns
+                                                                  utc-start
+                                                                  delta@start))
+                                                       (+ nano slope)))))
+                        (values (truncate-remainder utc-ns nano)
+                                (truncate-quotient utc-ns nano))))
+                    (car table)))
+            (else
+             (loop (cdr table)))))))
+
+
 ;;; the TIME structure; creates the accessors, too.
 
 (define-record-type time
-- 
2.19.1


--=-=-=--

Message sent to bug-guile@HIDDEN:

Subject: bug#26632: TAI<->UTC conversion botches 1961 to 1971
Resent-From: John Cowan <cowan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 24 Oct 2018 18:13:02 +0000
Resent-Message-ID: <handler.26632.B26632.154040472332734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Mark H Weaver <mhw@HIDDEN>
Cc: zefram@HIDDEN, 26632 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <20170424010218.GL6765@HIDDEN> <87zhv3yjhu.fsf@HIDDEN>
In-Reply-To: <87zhv3yjhu.fsf@HIDDEN>
From: John Cowan <cowan@HIDDEN>
Date: Wed, 24 Oct 2018 14:11:42 -0400
Message-ID: <CAD2gp_Teq_Mp4LZQy+6YAvJYq+9=cz3y94VNCtyymMq69e8abg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c9cb770578fd6b6f"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--000000000000c9cb770578fd6b6f
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 24, 2018 at 1:58 AM Mark H Weaver <mhw@HIDDEN> wrote:

> This has to be examined somewhat indirectly, because SRFI-19 doesn't offer
> > any way to display a TAI time in its conventional form as a date-like
> > structure, nor to input a TAI time from such a structure.
>

I think that is as it should be.  TAI time is a count of SI seconds from a
particular instant in time.  It is not divided up into minutes, hours,
days, months, years, etc. I realize that this is often done, but I believe
it to be not actually meaningful.  These terms apply to dynamical time and
also in a slightly different way to UTC, but they have little meaning for
TAI.

-- 
John Cowan          http://vrici.lojban.org/~cowan        cowan@HIDDEN
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."

--000000000000c9cb770578fd6b6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Wed, Oct 24, 2018 at 1:58 AM Mark H Weaver &lt;<a href=3D"mai=
lto:mhw@HIDDEN">mhw@HIDDEN</a>&gt; wrote:<br></div><div dir=3D"ltr"=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; This has =
to be examined somewhat indirectly, because SRFI-19 doesn&#39;t offer<br>
&gt; any way to display a TAI time in its conventional form as a date-like<=
br>
&gt; structure, nor to input a TAI time from such a structure.<br></blockqu=
ote><div><br></div><div>I think that is as it should be.=C2=A0 TAI time is =
a count of SI seconds from a particular instant in time.=C2=A0 It is not di=
vided up into minutes, hours, days, months, years, etc. I realize that this=
 is often done, but I believe it to be not actually meaningful.=C2=A0 These=
 terms apply to dynamical time and also in a slightly different way to UTC,=
 but they have little meaning for TAI.</div><div><br></div><div>--=C2=A0</d=
iv><div><div>John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:/=
/vrici.lojban.org/~cowan">http://vrici.lojban.org/~cowan</a>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 <a href=3D"mailto:cowan@HIDDEN">cowan@HIDDEN</a></div><di=
v>=C2=A0 =C2=A0 &quot;Mr. Lane, if you ever wish anything that I can do, al=
l you will have</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 to do will be to send=
 me a telegram asking and it will be done.&quot;</div><div>=C2=A0 =C2=A0 &q=
uot;Mr. Hearst, if you ever get a telegram from me asking you to do</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 anything, you can put the telegram down as a=
 forgery.&quot;<br><br></div></div></div></div></div>

--000000000000c9cb770578fd6b6f--

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26632: TAI<->UTC conversion botches 1961 to 1971
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Tue, 06 Nov 2018 04:22:01 +0000
Resent-Message-ID: <handler.26632.B26632.154147811128723 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26632
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: 26632 <at> debbugs.gnu.org
Received: via spool by 26632-submit <at> debbugs.gnu.org id=B26632.154147811128723
          (code B ref 26632); Tue, 06 Nov 2018 04:22:01 +0000
Received: (at 26632) by debbugs.gnu.org; 6 Nov 2018 04:21:51 +0000
Received: from localhost ([127.0.0.1]:35905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gJssB-0007TC-5x
	for submit <at> debbugs.gnu.org; Mon, 05 Nov 2018 23:21:51 -0500
Received: from river.fysh.org ([87.98.248.19]:36247 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zefram@HIDDEN>) id 1gJss9-0007T4-6N
 for 26632 <at> debbugs.gnu.org; Mon, 05 Nov 2018 23:21:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fysh.org;
 s=20170316; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
 Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=TPTkGLq96CT9m6CXLf2GUACkVLIV+1vaSVr1BfulrLc=; b=WJ6dnYuheKYYcC0cB5PjqbzCI5
 M3uYvBRNK+AGWrBIWktFmknnCqQpHX/fQ3L2q5Iq0WM9SHcXEnduUli6bz39XkMWRuBkxpfAKxWqH
 4s2O2k26w7GVTRW2OL5j5ZUG2PS/GdFztaqiA80iJx13JxRkyTtYN3aoElqt1hR0mT8M=;
Received: from zefram by river.fysh.org with local (Exim 4.89 #1 (Debian))
 id 1gJss4-00040y-3X; Tue, 06 Nov 2018 04:21:44 +0000
Date: Tue, 6 Nov 2018 04:21:44 +0000
From: Zefram <zefram@HIDDEN>
Message-ID: <20181106042144.rglcwbfdfmwo7dyc@HIDDEN>
References: <20170424010218.GL6765@HIDDEN>
 <87zhv3yjhu.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87zhv3yjhu.fsf@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Mark H Weaver wrote:
>patch adds the TAI-UTC tables for 1961-1971 and uses them to implement
>TAI<->UTC conversions over that time range with nanosecond accuracy.

On a quick inspection of the code, that looks good.

>        I'm vaguely concerned about violating widely-held assumptions,
>e.g. that UTC runs at the same rate as TAI

If an application assumes that for pre-1972 times, then the application
is broken.  Note that any application currently using the srfi-19 library
for pre-1972 TAI<->UTC conversions already has a bigger problem, in that
it's getting false answers from the library.  It's hard to see how fixing
the library could make any previously-working program stop working.

>             which might cause some code on top of Guile to misbehave if
>the system clock is set pre-1972,

If the system clock is incorrect by decades, there will be many other
problems to deal with.

>I'm curious to hear opinions on this.

My view is that this change should definitely be applied.  But it's also
worth thinking about what the alternative is, if the correct conversions
are somehow too shocking for innocent programs to be exposed to them.
Making no change isn't a realistic option: the library is producing
false answers, which are no use to anyone.  It's clearly a bug in the
library, and needs to be addressed somehow.  The only other defensible
option would be to declare pre-1972 UTC out of scope for the library,
having attempted conversions signal an error.  That would have to be
documented, and it seems like it would still amount to a deviation from
the requirements of SRFI-19.

-zefram

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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