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 23:53:24 -0400 Message-ID: <87efck0xcb.fsf@netris.org> References: <20151113142229.GO13455@fysh.org> <87woqc16kd.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540094116 3535 195.159.176.226 (21 Oct 2018 03:55:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2018 03:55:16 +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 05:55: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 1gE4pb-0000oO-E0 for guile-bugs@m.gmane.org; Sun, 21 Oct 2018 05:55:11 +0200 Original-Received: from localhost ([::1]:57367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE4rh-0002VZ-TB for guile-bugs@m.gmane.org; Sat, 20 Oct 2018 23:57:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE4rY-0002TS-5F for bug-guile@gnu.org; Sat, 20 Oct 2018 23:57:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gE4oU-00016M-Dh for bug-guile@gnu.org; Sat, 20 Oct 2018 23:54:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57682) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gE4oU-00016B-9H for bug-guile@gnu.org; Sat, 20 Oct 2018 23:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gE4oU-0004od-3a for bug-guile@gnu.org; Sat, 20 Oct 2018 23:54: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 03:54: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.154009402818483 (code B ref 21904); Sun, 21 Oct 2018 03:54:02 +0000 Original-Received: (at 21904) by debbugs.gnu.org; 21 Oct 2018 03:53:48 +0000 Original-Received: from localhost ([127.0.0.1]:33707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE4oG-0004o3-2W for submit@debbugs.gnu.org; Sat, 20 Oct 2018 23:53:48 -0400 Original-Received: from world.peace.net ([64.112.178.59]:48132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE4oE-0004nq-Lv for 21904@debbugs.gnu.org; Sat, 20 Oct 2018 23:53:47 -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 1gE4o8-0003cz-Pv; Sat, 20 Oct 2018 23:53:40 -0400 In-Reply-To: <87woqc16kd.fsf@netris.org> (Mark H. Weaver's message of "Sat, 20 Oct 2018 20:34:10 -0400") 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:9226 Archived-At: Mark H Weaver writes: > 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. I thought about it some more, and I'm now inclined to think that the approach in your patches is reasonable, or at least it's the least bad thing we can do when asked to print a year that doesn't fit within the standard format, given the existing SRFI-19 API. I also just noticed that the SRFI-19's reference implementation's formatting of negative years is very badly broken (e.g. it prints "00-2" when the year field is -2) and Guile had the same behavior after I applied the fix from upstream to pad the year to 4 digits. So, for now, I went ahead and implemented the behavior that you recommended, with one difference: where you hardcode the padding character to #\0 when formatting years, I use the padding character specified by the user, following the SRFI-19 reference implementation. What do you think? Mark