A patch to fix this is attached.  It applies on top of my patch for
bug#21904.  The choice that I described for that bug about whether
to change ~Y or to have a separate ISO 8601 year formatter actually
applies to both bugs, and the comment that I made there about exposing
the non-linear year numbering is really only about this bug.

-zefram
>From 3d39f1dfa0e210282db48a9af828646d7e9acef3 Mon Sep 17 00:00:00 2001
From: Zefram <zef...@fysh.org>
Date: Thu, 20 Apr 2017 00:53:40 +0100
Subject: [PATCH 2/2] fix SRFI-19's ISO 8601 year numbering

The ISO 8601 date formats offered by SRFI-19's date->string function
were emitting incorrect year numbers for years preceding AD 1.  It was
following the non-linear numbering that the library uses in the date
structure, rather than the standard astronomical year numbering required
by ISO 8601.  This is now fixed.  As with the preceding fix for the
syntax of year numbers, the fix is actually applied to the ~Y format,
which SRFI-19 doesn't require to follow ISO 8601.
---
 module/srfi/srfi-19.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/module/srfi/srfi-19.scm b/module/srfi/srfi-19.scm
index d4308bb..0e56c31 100644
--- a/module/srfi/srfi-19.scm
+++ b/module/srfi/srfi-19.scm
@@ -1128,7 +1128,8 @@
                                       2)
                         port)))
    (cons #\Y (lambda (date pad-with port)
-	       (let ((y (date-year date)))
+	       (let* ((yy (date-year date))
+		      (y (if (negative? yy) (+ yy 1) yy)))
 		 (cond ((negative? y) (display #\- port))
 		       ((>= y 10000) (display #\+ port)))
 		 (display (padding (abs y) #\0 4) port))))
-- 
2.1.4

Reply via email to