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#21904: date->string duff ISO 8601 format for non-4-digit years Date: Sat, 20 Oct 2018 20:34:10 -0400 Message-ID: <87woqc16kd.fsf@netris.org> References: <20151113142229.GO13455@fysh.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540081995 28802 195.159.176.226 (21 Oct 2018 00:33:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2018 00:33:15 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 21904@debbugs.gnu.org To: Zefram Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Oct 21 02:33:11 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 1gE1g5-0007Mk-SP for guile-bugs@m.gmane.org; Sun, 21 Oct 2018 02:33:09 +0200 Original-Received: from localhost ([::1]:57021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE1iB-0000PN-Vg for guile-bugs@m.gmane.org; Sat, 20 Oct 2018 20:35:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE1hy-0000Nb-2K for bug-guile@gnu.org; Sat, 20 Oct 2018 20:35:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gE1hu-0006rK-Tx for bug-guile@gnu.org; Sat, 20 Oct 2018 20:35:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57619) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gE1hu-0006r9-Pv for bug-guile@gnu.org; Sat, 20 Oct 2018 20:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gE1hu-0000Ba-Bv for bug-guile@gnu.org; Sat, 20 Oct 2018 20:35: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: Sun, 21 Oct 2018 00:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21904 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 21904-submit@debbugs.gnu.org id=B21904.1540082078680 (code B ref 21904); Sun, 21 Oct 2018 00:35:02 +0000 Original-Received: (at 21904) by debbugs.gnu.org; 21 Oct 2018 00:34:38 +0000 Original-Received: from localhost ([127.0.0.1]:33644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE1hV-0000At-QS for submit@debbugs.gnu.org; Sat, 20 Oct 2018 20:34:38 -0400 Original-Received: from world.peace.net ([64.112.178.59]:41578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE1hU-0000Ag-Tf for 21904@debbugs.gnu.org; Sat, 20 Oct 2018 20:34:37 -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 1gE1hN-0001hS-TU; Sat, 20 Oct 2018 20:34:30 -0400 In-Reply-To: <20151113142229.GO13455@fysh.org> (Zefram's message of "Fri, 13 Nov 2015 14:22:29 +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:9223 Archived-At: Zefram writes: > For year numbers 10000 and above, it is necessary to use more than four > digits for the year, and that's permitted, but ISO 8601 requires that > more than four digits are preceded by a sign. For positive year numbers > the sign must be "+". So one should write "+22666" rather than "22666", > for example. I skimmed a draft of ISO 8601 that I was able to find gratis online: https://web.archive.org/web/20171019211402/https://www.loc.gov/standards/= datetime/ISO_DIS%208601-1.pdf https://web.archive.org/web/20171020000043/https://www.loc.gov/standards/= datetime/ISO_DIS%208601-2.pdf and also the ISO 8601 Wikipedia page: https://en.wikipedia.org/wiki/ISO_8601#Years and I'm left with a different interpretation about what the standard permits. As the Wikipedia page says: To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[19] An expanded year representation [=C2=B1YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or =E2=88=92 sign[20] [...] Note the words "but only by prior agreement between the sender and the receiver", and "must have an agreed-upon number of extra year digits". You seem to have reached the conclusion that the sender can choose the number of digits dynamically, leaving the receiver to auto-detect the number of digits, but that seems to contradict to requirements given above. My interpretation is that although ISO 8601 permits the use of expanded year formats, it seems to require that in a given format, the year must have a fixed number of digits, and it must _always_ include a sign. In other words, the receiver should know ahead of time, by prior agreement, how many digits to expect, and there should _always_ be a sign, even if the year happens to be in the range 0-9999. In order to support years outside the range 0-9999 and in accordance with ISO 8601, I think that 'date->string' and 'string->date' would need to be extended to allow the caller to specify how many digits to use in the expanded 'year' format, presumably by adding a new format escape. If the specified number of digits is greater than 4, then a sign would *always* be printed. 'string->date' would know how many digits to expect, and whether to expect a sign. Ideally, such an extension of 'date->string' and 'string->date' would be adopted by upstream SRFI-19. However, if that's unsuccessful, I'd be open to unilaterally adding such an extension. There's precedent for this in Guile, e.g. see our (srfi srfi-9 gnu) extensions to SRFI-9. Another question is whether or not we should raise an exception when attempting to print a year that cannot be represented in the requested year format. What do you think? Mark