Received: (at 21912) by debbugs.gnu.org; 22 Oct 2018 14:50:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 22 10:50:56 2018 Received: from localhost ([127.0.0.1]:36345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gEbXk-0000uK-46 for submit <at> debbugs.gnu.org; Mon, 22 Oct 2018 10:50:56 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:35778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <cowan@HIDDEN>) id 1gEbXi-0000u1-7y for 21912 <at> debbugs.gnu.org; Mon, 22 Oct 2018 10:50:54 -0400 Received: by mail-wr1-f52.google.com with SMTP id w5-v6so45276066wrt.2 for <21912 <at> debbugs.gnu.org>; Mon, 22 Oct 2018 07:50:54 -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=Ape9DpTAIJSNxDXvu4Yk2ffgH69oPQdP2gaz6paDkSA=; b=cjrst7WQQRUkoCM1HIEtw6F8A3dJe/HoUd9j2bACSI1EEpvKDSKOJ57sep0A/3/up/ dF4EFYr/GpmSN/IBwFb/lJJTCKF/a3It0zwrVBOH64ziH0xBSG/axIfCOkMAXGRqll6R syW9OGmMUUn6EHKO5nkTdi06xPGyXgcQ0+xrSqCkaE4mlOjLrIGqqNuVGsULZVEMcd+G +fEbtBRhUljx7m/d2nla/thWMTAx0T65N1mE9d8vVDABvUGI8fEfCyL1NubM1gJZo6S0 OuQuvA/87IXSpp6rQQMrTNuJk8eplpr8FKABNHEp/cJYKaXWnOVG/umartIHTQAmKq4x 3jDQ== 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=Ape9DpTAIJSNxDXvu4Yk2ffgH69oPQdP2gaz6paDkSA=; b=qVOZTpdTM532Qmpzko8px/KpuFmJaOZld1DxxAtqktQ8uJfW4g5aVanUfC0RaN1tGe 1INarL6NMb7OZge6KCRaMqecHEpU80pXSNpLZLB4HtOd7IrCvPNmZLHIr/NM0oQX3b2I QhcBiyIR5W8ZE+RPKew18g3SWIwVNdkEBkBNlNHa0E1dVQ5z2HICMc7mkuiYNtnpdMNf bxOmADu57B36gR5/D/o1xMGzOqo2VsUR0l6SvkhfQSDEEJYeS+gZmdWDLZw85LNkzz+t uJbO6LLYKeBswfwIabL4k8hu/tYiPM4b6sizXbMZw8I4W56GKsTKDk+ENSfUE6Mcu0Vq +x7w== X-Gm-Message-State: ABuFfojVvKOlX9VyfCgjum9uegiRPGFvm9FJtJy744QXLQAl5mOPcSve xA0APm85wHABhNqvVa63rVs0v9O2tUcvtKE15ginNQ== X-Google-Smtp-Source: ACcGV604tJm7/ucs0w+HUsQlCjvVvEl9IQLflMbRW4lt7IahALW3CYZ/tXiTvb9MkA9DXPD4c3gOAwy+C/+X1vmKgCk= X-Received: by 2002:adf:a447:: with SMTP id e7-v6mr45925619wra.190.1540219848215; Mon, 22 Oct 2018 07:50:48 -0700 (PDT) MIME-Version: 1.0 References: <20151113164427.GS13455@HIDDEN> <87woqc2r5x.fsf@HIDDEN> <CAD2gp_Ru5sOoxPN5un7=OFCJd-B8OiZyNrkqs5-nBxO+=_JoRQ@HIDDEN> <871s8ia5mk.fsf@HIDDEN> In-Reply-To: <871s8ia5mk.fsf@HIDDEN> From: John Cowan <cowan@HIDDEN> Date: Mon, 22 Oct 2018 10:50:37 -0400 Message-ID: <CAD2gp_QxJ=jwecOrt+=RzKHrjCjqWT0MrfHUG7wb7ekyahPovQ@HIDDEN> Subject: Re: bug#21912: TAI<->UTC conversion botches the unknown To: Mark H Weaver <mhw@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000ede7100578d26051" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 21912 Cc: zefram@HIDDEN, 21912 <at> debbugs.gnu.org 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 (-) --000000000000ede7100578d26051 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 22, 2018 at 1:54 AM Mark H Weaver <mhw@HIDDEN> wrote: > This means that TAI-UTC = 4.2131700 + (MJD - 39126) * 0.002592, where > MJD is the modified julian day of the desired TAI-UTC delta. In this > case, the MJD (modified julian day) of midnight UTC January 1, 1970 is > 40587, and plugging that into the equation above yields TAI-UTC = > 8.000082 seconds. > Thanks. I have changed the errata list, the R7RS source (in the "errata" branch), and the cached copy of r7rs.pdf. --000000000000ede7100578d26051 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon= , Oct 22, 2018 at 1:54 AM Mark H Weaver <<a href=3D"mailto:mhw@HIDDEN= g">mhw@HIDDEN</a>> wrote:<br></div><div>=C2=A0</div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> This means that TAI-UTC =3D 4.2131700 + (MJD - 39126) * 0.002592, where<br> MJD is the modified julian day of the desired TAI-UTC delta.=C2=A0 In this<= br> case, the MJD (modified julian day) of midnight UTC January 1, 1970 is<br> 40587, and plugging that into the equation above yields TAI-UTC =3D<br> 8.000082 seconds.<br></blockquote><div><br></div><div>Thanks.=C2=A0 I have = changed the errata list, the R7RS source (in the "errata" branch)= , and the cached copy of r7rs.pdf.=C2=A0</div></div></div> --000000000000ede7100578d26051--
bug-guile@HIDDEN:bug#21912; Package guile.
Full text available.
Received: (at 21912) by debbugs.gnu.org; 22 Oct 2018 05:54:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 22 01:54:34 2018
Received: from localhost ([127.0.0.1]:35023 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gETAf-0002LG-Rz
for submit <at> debbugs.gnu.org; Mon, 22 Oct 2018 01:54:34 -0400
Received: from world.peace.net ([64.112.178.59]:52910)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1gETAd-0002Kz-0Z
for 21912 <at> debbugs.gnu.org; Mon, 22 Oct 2018 01:54:32 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1gETAW-0007oe-Aj; Mon, 22 Oct 2018 01:54:24 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: John Cowan <cowan@HIDDEN>
Subject: Re: bug#21912: TAI<->UTC conversion botches the unknown
References: <20151113164427.GS13455@HIDDEN> <87woqc2r5x.fsf@HIDDEN>
<CAD2gp_Ru5sOoxPN5un7=OFCJd-B8OiZyNrkqs5-nBxO+=_JoRQ@HIDDEN>
Date: Mon, 22 Oct 2018 01:54:11 -0400
In-Reply-To: <CAD2gp_Ru5sOoxPN5un7=OFCJd-B8OiZyNrkqs5-nBxO+=_JoRQ@HIDDEN>
(John Cowan's message of "Sun, 21 Oct 2018 08:50:38 -0400")
Message-ID: <871s8ia5mk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 21912
Cc: zefram@HIDDEN, 21912 <at> debbugs.gnu.org
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 (-)
Hi John,
John Cowan <cowan@HIDDEN> writes:
> 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>.
Actually, the correct TAI-UTC delta on January 1, 1970 TAI is
approximately 8 seconds. You are misinterpreting the relevant line from
that file:
1968 FEB 1 =JD 2439887.5 TAI-UTC= 4.2131700 S + (MJD - 39126.) X 0.002592 S
This means that TAI-UTC = 4.2131700 + (MJD - 39126) * 0.002592, where
MJD is the modified julian day of the desired TAI-UTC delta. In this
case, the MJD (modified julian day) of midnight UTC January 1, 1970 is
40587, and plugging that into the equation above yields TAI-UTC =
8.000082 seconds.
If you are doubtful, see the "Atomic Time and Leap Seconds" graph, which
shows a graph of TAI-UTC over the years 1958 to 2017, on the following page:
http://jjy.nict.go.jp/mission/page1-e.html
Note that between January 1961 and January 1972, the TAI-UTC delta was
not an integer, and instead of the discontinuous leap second jumps that
we've had since 1972, the two clocks ran at different rates in those
years.
Mark
bug-guile@HIDDEN:bug#21912; Package guile.
Full text available.Received: (at 21912) by debbugs.gnu.org; 21 Oct 2018 12:50:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 21 08:50:59 2018 Received: from localhost ([127.0.0.1]:33820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gEDC6-0003F7-Jn for submit <at> debbugs.gnu.org; Sun, 21 Oct 2018 08:50:58 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:34943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <cowan@HIDDEN>) id 1gEDC3-0003Eq-QL for 21912 <at> debbugs.gnu.org; Sun, 21 Oct 2018 08:50:57 -0400 Received: by mail-wm1-f53.google.com with SMTP id o17-v6so6916935wmh.0 for <21912 <at> 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) MIME-Version: 1.0 References: <20151113164427.GS13455@HIDDEN> <87woqc2r5x.fsf@HIDDEN> In-Reply-To: <87woqc2r5x.fsf@HIDDEN> From: John Cowan <cowan@HIDDEN> Date: Sun, 21 Oct 2018 08:50:38 -0400 Message-ID: <CAD2gp_Ru5sOoxPN5un7=OFCJd-B8OiZyNrkqs5-nBxO+=_JoRQ@HIDDEN> Subject: Re: bug#21912: TAI<->UTC conversion botches the unknown To: Mark H Weaver <mhw@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000009cd260578bc967b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 21912 Cc: zefram@HIDDEN, 21912 <at> debbugs.gnu.org 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 (-) --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 <mhw@HIDDEN> wrote: > Zefram <zefram@HIDDEN> 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 <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 > 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 <div dir=3D"ltr"><div dir=3D"ltr">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:<div><br></div><div>(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.<br></div><div><br></di= v><div>I now see that the "ten seconds" is incorrect, and I am fi= ling an erratum: the correct figure is=C2=A0<span style=3D"color:rgb(0,0,0)= ;white-space:pre-wrap">4.2131700 seconds per <</span><font color=3D"#000= 000"><span style=3D"white-space:pre-wrap"><a href=3D"http://maia.usno.navy.= mil/ser7/tai-utc.dat">http://maia.usno.navy.mil/ser7/tai-utc.dat</a>>.</= span></font></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt= r">On Sat, Oct 20, 2018 at 6:25 PM Mark H Weaver <<a href=3D"mailto:mhw@= netris.org">mhw@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex">Zefram <<a href=3D"mailto:zefram@HIDDEN" target=3D"_blank">zefr= am@HIDDEN</a>> writes:<br> <br> > 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<br> > its scope.<br> <br> I sympathize with your preference to raise an error rather than return<br> invalid results, but unfortunately I don't think this proposal is reall= y<br> 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<br> uses UTC for all julian days, modified julian days, and dates.=C2=A0 For<br= > example, 'time-tai->date' and 'time-tai->julian-day' = include an implicit<br> conversion to UTC.<br> <br> As a result, if we were to adopt your proposal, it would never be<br> possible to print a date more than 6 months in the future, and for users<br= > of stable distributions such as Debian, it is not be possible to print<br> the current date.<br> <br> We need a way to print future dates.=C2=A0 In theory, we could print future= <br> dates in TAI without the leap second table, using the convention of<br> printing TAI dates as in <<a href=3D"https://cr.yp.to/proto/utctai.html"= rel=3D"noreferrer" target=3D"_blank">https://cr.yp.to/proto/utctai.html</a= >>, but<br> that's not what SRFI-19 does, and it has no API to support that way of<= br> printing TAI dates.<br> <br> Also, it's debatable whether it's desirable to print future dates i= n TAI<br> this way, since in the far future the times will drift far away from<br> mean solar time, and the calendar will eventually drift from the usual<br> alignment of the solar year to the months on the calendar.<br> <br> So, I think this is a valid issue, but I don't see how it can be<br> addressed within SRFI-19.=C2=A0 I would need to be addressed in a new SRFI,= <br> and even then it's not clear to me what's the right way forward.<br= > <br> What do you think?<br> <br> =C2=A0 =C2=A0 Regards,<br> =C2=A0 =C2=A0 =C2=A0 Mark<br> <br> <br> <br> </blockquote></div> --00000000000009cd260578bc967b--
bug-guile@HIDDEN:bug#21912; Package guile.
Full text available.
Received: (at 21912) by debbugs.gnu.org; 20 Oct 2018 22:24:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 20 18:24:20 2018
Received: from localhost ([127.0.0.1]:33564 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gDzfP-0001TS-Tz
for submit <at> debbugs.gnu.org; Sat, 20 Oct 2018 18:24:20 -0400
Received: from world.peace.net ([64.112.178.59]:35000)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1gDzfO-0001TF-07
for 21912 <at> debbugs.gnu.org; Sat, 20 Oct 2018 18:24:18 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1gDzfH-0008Tn-3w; Sat, 20 Oct 2018 18:24:12 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: Zefram <zefram@HIDDEN>
Subject: Re: bug#21912: TAI<->UTC conversion botches the unknown
References: <20151113164427.GS13455@HIDDEN>
Date: Sat, 20 Oct 2018 18:23:54 -0400
In-Reply-To: <20151113164427.GS13455@HIDDEN> (Zefram's message of "Fri, 13
Nov 2015 16:44:27 +0000")
Message-ID: <87woqc2r5x.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 21912
Cc: 21912 <at> debbugs.gnu.org
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 (-)
Zefram <zefram@HIDDEN> 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 <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
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
bug-guile@HIDDEN:bug#21912; Package guile.
Full text available.Received: (at submit) by debbugs.gnu.org; 13 Nov 2015 16:44:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 13 11:44:56 2015 Received: from localhost ([127.0.0.1]:37377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ZxHT5-0000dg-Lf for submit <at> debbugs.gnu.org; Fri, 13 Nov 2015 11:44:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37965) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <zefram@HIDDEN>) id 1ZxHSl-0000dG-Qs for submit <at> debbugs.gnu.org; Fri, 13 Nov 2015 11:44:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1ZxHSk-0005i6-BP for submit <at> debbugs.gnu.org; Fri, 13 Nov 2015 11:44:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1ZxHSk-0005i2-8Z for submit <at> debbugs.gnu.org; Fri, 13 Nov 2015 11:44:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1ZxHSj-0006IX-7U for bug-guile@HIDDEN; Fri, 13 Nov 2015 11:44:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1ZxHSi-0005hS-8S for bug-guile@HIDDEN; Fri, 13 Nov 2015 11:44:33 -0500 Received: from river6.fysh.org ([2001:41d0:d:20da::2]:40025 helo=river.fysh.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1ZxHSi-0005h7-0V for bug-guile@HIDDEN; Fri, 13 Nov 2015 11:44:32 -0500 Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1ZxHSd-0005q8-M0; Fri, 13 Nov 2015 16:44:27 +0000 Date: Fri, 13 Nov 2015 16:44:27 +0000 From: Zefram <zefram@HIDDEN> To: bug-guile@HIDDEN Subject: TAI<->UTC conversion botches the unknown Message-ID: <20151113164427.GS13455@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -4.0 (----) Probing the existence of leap seconds on particular days, via srfi-19's TAI-to-UTC conversion. The methodology here is to take noon UT on the day of interest, convert to TAI, add 86400 seconds, then convert to UTC and display. The resulting time of day is 11:59:59 if there is a leap second that day, and 12:00:00 if there is not. scheme@(guile-user)> (use-modules (srfi srfi-19)) scheme@(guile-user)> (date->string (time-tai->date (add-duration (julian-day->time-tai 2455743) (make-time time-duration 0 86400)) 0) "~4") $1 = "2011-07-01T12:00:00Z" scheme@(guile-user)> (date->string (time-tai->date (add-duration (julian-day->time-tai 2456109) (make-time time-duration 0 86400)) 0) "~4") $2 = "2012-07-01T11:59:59Z" scheme@(guile-user)> (date->string (time-tai->date (add-duration (julian-day->time-tai 2457204) (make-time time-duration 0 86400)) 0) "~4") $3 = "2015-07-01T12:00:00Z" scheme@(guile-user)> (date->string (time-tai->date (add-duration (julian-day->time-tai 2457935) (make-time time-duration 0 86400)) 0) "~4") $4 = "2017-07-01T12:00:00Z" For 2011-06-30 it is correct that there was not a leap second, and for 2012-06-30 it is correct that there was. But for 2015-06-30 it says there was not a leap second, when in fact there was. For 2017-06-30 it says there will not be a leap second, when in fact it is not yet determined whether there will be. Really both of these errors come from the same cause. At the time this Guile 2.0.11 was released, the leap status of 2015-06-30 had not yet been determined. Both 2015 and 2017 fall within the future period beyond the scope of this Guile's static leap second knowledge. The bug is not that Guile doesn't know that there was a leap second in 2015. As the 2017 case illustrates, it's impossible for it to know all the leap second scheduling about which it can be asked. The bug is that Guile *thinks* it knows about all future leap seconds. It specifically thinks that there will be no leaps at all beyond the historically-scheduled ones that it knows about. 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. -zefram
Zefram <zefram@HIDDEN>:bug-guile@HIDDEN.
Full text available.bug-guile@HIDDEN:bug#21912; Package guile.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.