From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Cowan Newsgroups: gmane.lisp.guile.bugs Subject: bug#21912: TAI<->UTC conversion botches the unknown Date: Sun, 21 Oct 2018 08:50:38 -0400 Message-ID: References: <20151113164427.GS13455@fysh.org> <87woqc2r5x.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000009cd260578bc967b" X-Trace: blaine.gmane.org 1540127547 13034 195.159.176.226 (21 Oct 2018 13:12:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2018 13:12:27 +0000 (UTC) Cc: zefram@fysh.org, 21912@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Oct 21 15:12:23 2018 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEDWo-0003Ig-7k for guile-bugs@m.gmane.org; Sun, 21 Oct 2018 15:12:22 +0200 Original-Received: from localhost ([::1]:58816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEDYu-0004jq-L4 for guile-bugs@m.gmane.org; Sun, 21 Oct 2018 09:14:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEDQm-00057Q-BL for bug-guile@gnu.org; Sun, 21 Oct 2018 09:06:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEDCB-0001IM-3Y for bug-guile@gnu.org; Sun, 21 Oct 2018 08:51:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57795) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gEDCA-0001IC-To for bug-guile@gnu.org; Sun, 21 Oct 2018 08:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gEDC9-0003FO-LW for bug-guile@gnu.org; Sun, 21 Oct 2018 08:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: John Cowan Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 21 Oct 2018 12:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21912 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 21912-submit@debbugs.gnu.org id=B21912.154012625912473 (code B ref 21912); Sun, 21 Oct 2018 12:51:01 +0000 Original-Received: (at 21912) by debbugs.gnu.org; 21 Oct 2018 12:50:59 +0000 Original-Received: from localhost ([127.0.0.1]:33820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEDC6-0003F7-Jn for submit@debbugs.gnu.org; Sun, 21 Oct 2018 08:50:58 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:34943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEDC3-0003Eq-QL for 21912@debbugs.gnu.org; Sun, 21 Oct 2018 08:50:57 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id o17-v6so6916935wmh.0 for <21912@debbugs.gnu.org>; Sun, 21 Oct 2018 05:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZeIg4w3JRO6kci0bYFxGf6PUJUpnD90WmPJlLndpQdg=; b=pPPfQyJyx0DwF7iZRutkGY2/UWaC+k0rlJW4atB9kMBJxPf2RDZIhXeBnRrPVusVuc db8iPsN/i07/hCfRn6kXeXi3OrmX2jtycIf54hoJC7GNJxXqrhuApI7yfRZIW6vQcOHw L56sVYQbhllEEP5a81GpaltFqD0oeH+bj54Kx7RQtL8HyGqLPoXYhY30SuNB9ctx47XJ 2V13c6VG3visA9QB0LAkV5vbMbluDu2CN6Fcj1HDE/hUO6qm0p+l4YZs69XcQ67F7X4C /k/K04Yq4R9NHwLSSZ96sjhQkPyUxZlmqep2VQ9AqgC1Ej7pMaSXhid+gior3QENHsxX 41aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZeIg4w3JRO6kci0bYFxGf6PUJUpnD90WmPJlLndpQdg=; b=W1b1ybZ+7Fld7/P9+zZcYcHpJV5t46fhaRNzNamjYtenaQpnPlYUxEr+0yai6/clRk UhrcDIa3A6hz37PDeT3UrSgJ8ONUPF5pGXCCZ6UXbEUYGmxdHu8ykXg0crf4hUdGLkZE rQ9jBS5rjQXaVk0BQa6PD9xCX5EhCePwnuwocX6JaPAAWlpYGmfGrT7HseRO2xXfhpym nMtYKlAqejVjblNvVal5j0kIidf24rHvo51MVFVsyG0+sUfXYIGjePg6GZ7+Dx3k8XQX FixNCoSvYaotL5dsvW1Trlmzb0BqUCq6r5RWKjGP4ILb/Upt0lOjF0QHCNzaLxsgF4ja czrw== X-Gm-Message-State: ABuFfojoQCg1N8eCQlOrBowN8w+CFB+gBsi4+iJ2yMTDBdtGmlvg4rwU 4sAm2I+y1Irv6OiKG2qr/DJoF38DpZjuCuTyi1CBKw== X-Google-Smtp-Source: ACcGV63GesCa9adaqzUUjq9J/Ka+NK0Q3SGmFUgaikP64cS1Bh/gpyaXVmE9WxoAPb0mxlHthweR3NLP9yRNhcbxY2Q= X-Received: by 2002:a1c:3702:: with SMTP id e2-v6mr11206051wma.89.1540126249956; Sun, 21 Oct 2018 05:50:49 -0700 (PDT) In-Reply-To: <87woqc2r5x.fsf@netris.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:9228 Archived-At: --00000000000009cd260578bc967b Content-Type: text/plain; charset="UTF-8" What is more, there are no TAI<->UTC conversion tables from before 1961 (when UTC began) and probably never will be. There was heated debate in the R7RS-small working group, and we finally settled on a compromise: (current-second) [r]eturns an inexact number representing the current time on the International Atomic Time (TAI) scale. The value 0.0 represents midnight on January 1, 1970 TAI (equivalent to ten seconds before midnight Universal Time) and the value 1.0 represents one TAI second later. Neither high accuracy nor high precision are required; in particular, returning Coordinated Universal Time plus a suitable constant might be the best an implementation can do. I now see that the "ten seconds" is incorrect, and I am filing an erratum: the correct figure is 4.2131700 seconds per < http://maia.usno.navy.mil/ser7/tai-utc.dat>. On Sat, Oct 20, 2018 at 6:25 PM Mark H Weaver wrote: > Zefram writes: > > > Guile ought to be aware of how far its leap table extends, and signal > > an error when asked to perform a TAI<->UTC conversion that falls outside > > its scope. > > I sympathize with your preference to raise an error rather than return > invalid results, but unfortunately I don't think this proposal is really > practical, given the SRFI-19 API. The main problem is that, although > it's not specified in the document, the SRFI-19 reference implementation > uses UTC for all julian days, modified julian days, and dates. For > example, 'time-tai->date' and 'time-tai->julian-day' include an implicit > conversion to UTC. > > As a result, if we were to adopt your proposal, it would never be > possible to print a date more than 6 months in the future, and for users > of stable distributions such as Debian, it is not be possible to print > the current date. > > We need a way to print future dates. In theory, we could print future > dates in TAI without the leap second table, using the convention of > printing TAI dates as in , but > that's not what SRFI-19 does, and it has no API to support that way of > printing TAI dates. > > Also, it's debatable whether it's desirable to print future dates in TAI > this way, since in the far future the times will drift far away from > mean solar time, and the calendar will eventually drift from the usual > alignment of the solar year to the months on the calendar. > > So, I think this is a valid issue, but I don't see how it can be > addressed within SRFI-19. I would need to be addressed in a new SRFI, > and even then it's not clear to me what's the right way forward. > > What do you think? > > Regards, > Mark > > > > --00000000000009cd260578bc967b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is more, there are no TAI<->UT= C conversion tables from before 1961 (when UTC began) and probably never wi= ll be.=C2=A0 There was heated debate in the R7RS-small working group, and w= e finally settled on a compromise:

(current-second) [r]e= turns an inexact number representing the current time on the International Atomic Time (TAI) scale. The value 0.0 represents midnight on January 1, 1970 TAI (equivalent to ten seconds before midnight Universal Time) and the value 1.0 represents one TAI second later. Neither high accuracy nor high precision are required; in particular, returning Coordinated Universal Time plus a suitable constant might be the best an implementation can do.

I now see that the "ten seconds" is incorrect, and I am fi= ling an erratum: the correct figure is=C2=A04.2131700 seconds per <http://maia.usno.navy.mil/ser7/tai-utc.dat>.

On Sat, Oct 20, 2018 at 6:25 PM Mark H Weaver <mhw@netris.org> wrote:
Zefram <zefr= am@fysh.org> writes:

> Guile ought to be aware of how far its leap table extends, and signal<= br> > an error when asked to perform a TAI<->UTC conversion that falls= outside
> its scope.

I sympathize with your preference to raise an error rather than return
invalid results, but unfortunately I don't think this proposal is reall= y
practical, given the SRFI-19 API.=C2=A0 The main problem is that, although<= br> it's not specified in the document, the SRFI-19 reference implementatio= n
uses UTC for all julian days, modified julian days, and dates.=C2=A0 For example, 'time-tai->date' and 'time-tai->julian-day' = include an implicit
conversion to UTC.

As a result, if we were to adopt your proposal, it would never be
possible to print a date more than 6 months in the future, and for users of stable distributions such as Debian, it is not be possible to print
the current date.

We need a way to print future dates.=C2=A0 In theory, we could print future=
dates in TAI without the leap second table, using the convention of
printing TAI dates as in <https://cr.yp.to/proto/utctai.html>, but
that's not what SRFI-19 does, and it has no API to support that way of<= br> printing TAI dates.

Also, it's debatable whether it's desirable to print future dates i= n TAI
this way, since in the far future the times will drift far away from
mean solar time, and the calendar will eventually drift from the usual
alignment of the solar year to the months on the calendar.

So, I think this is a valid issue, but I don't see how it can be
addressed within SRFI-19.=C2=A0 I would need to be addressed in a new SRFI,=
and even then it's not clear to me what's the right way forward.
What do you think?

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 Mark



--00000000000009cd260578bc967b--