From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#21912: TAI<->UTC conversion botches the unknown Date: Sat, 20 Oct 2018 18:23:54 -0400 Message-ID: <87woqc2r5x.fsf@netris.org> References: <20151113164427.GS13455@fysh.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540074191 29559 195.159.176.226 (20 Oct 2018 22:23:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 22:23:11 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 21912@debbugs.gnu.org To: Zefram Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Oct 21 00:23:07 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 1gDzeC-0007XY-FF for guile-bugs@m.gmane.org; Sun, 21 Oct 2018 00:23:04 +0200 Original-Received: from localhost ([::1]:56763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDzgI-00035L-NP for guile-bugs@m.gmane.org; Sat, 20 Oct 2018 18:25:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDzgB-00033p-Ez for bug-guile@gnu.org; Sat, 20 Oct 2018 18:25:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDzg6-0001wX-Pz for bug-guile@gnu.org; Sat, 20 Oct 2018 18:25:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57539) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDzg6-0001wJ-Lh for bug-guile@gnu.org; Sat, 20 Oct 2018 18:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gDzg6-0001UO-Et for bug-guile@gnu.org; Sat, 20 Oct 2018 18:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 20 Oct 2018 22:25:02 +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.15400742605675 (code B ref 21912); Sat, 20 Oct 2018 22:25:02 +0000 Original-Received: (at 21912) by debbugs.gnu.org; 20 Oct 2018 22:24:20 +0000 Original-Received: from localhost ([127.0.0.1]:33564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzfP-0001TS-Tz for submit@debbugs.gnu.org; Sat, 20 Oct 2018 18:24:20 -0400 Original-Received: from world.peace.net ([64.112.178.59]:35000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzfO-0001TF-07 for 21912@debbugs.gnu.org; Sat, 20 Oct 2018 18:24:18 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gDzfH-0008Tn-3w; Sat, 20 Oct 2018 18:24:12 -0400 In-Reply-To: <20151113164427.GS13455@fysh.org> (Zefram's message of "Fri, 13 Nov 2015 16:44:27 +0000") 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:9219 Archived-At: 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