bug#21903: date->string duff ISO 8601 negative years

bug#21903: date->string duff ISO 8601 negative years

[Zefram]

The date->string function from (srfi srfi-19), used on ISO 8601 formats
"~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
$1 = "-4714-11-24T12:00:00Z"

The date in question, the JD epoch, is 24 November 4714 BC (in the
proleptic Gregorian calendar).  In ISO 8601 format, that year is properly
represented as "-4713", not "-4714", because ISO 8601 uses the AD era
exclusively.  4714 BC = AD -4713.

-zefram

bug#21903: date->string duff ISO 8601 negative years

[Zefram]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

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

[-- Attachment #2: 0002-fix-SRFI-19-s-ISO-8601-year-numbering.patch --]
[-- Type: text/x-diff, Size: 1317 bytes --]

From 3d39f1dfa0e210282db48a9af828646d7e9acef3 Mon Sep 17 00:00:00 2001
From: Zefram <zefram@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

bug#21903: date->string duff ISO 8601 negative years

[Mark H Weaver]

Zefram <zefram@fysh.org> writes:

> The date->string function from (srfi srfi-19), used on ISO 8601 formats
> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
> $1 = "-4714-11-24T12:00:00Z"
>
> The date in question, the JD epoch, is 24 November 4714 BC (in the
> proleptic Gregorian calendar).  In ISO 8601 format, that year is properly
> represented as "-4713", not "-4714", because ISO 8601 uses the AD era
> exclusively.  4714 BC = AD -4713.

I agree that this is definitely a bug, but I'm nervous about deviating
from the SRFI-19 reference implementation, and therefore probably from
most other implementations of SRFI-19, in this way.

I think that this bug should be reported to the SRFI-19 mailing list.

   https://srfi.schemers.org/srfi-19/

There have been several other bugs reported and fixed in upstream
SRFI-19 over the years, including some as recently as June 2017, so I'm
hopeful that they will take this bug seriously and issue a fix.

Would you like to report it to them?

       Mark

bug#21903: date->string duff ISO 8601 negative years

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Zefram <zefram@fysh.org> writes:
>
>> The date->string function from (srfi srfi-19), used on ISO 8601 formats
>> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>>
>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>> scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
>> $1 = "-4714-11-24T12:00:00Z"
>>
>> The date in question, the JD epoch, is 24 November 4714 BC (in the
>> proleptic Gregorian calendar).  In ISO 8601 format, that year is properly
>> represented as "-4713", not "-4714", because ISO 8601 uses the AD era
>> exclusively.  4714 BC = AD -4713.
>
> I agree that this is definitely a bug, but I'm nervous about deviating
> from the SRFI-19 reference implementation, and therefore probably from
> most other implementations of SRFI-19, in this way.

Also see my comments here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21904#17

which mention that ISO 8601 apparently requires that the sender and
receiver agree ahead of time whether an extended format will be used, in
which case a sign is *always* required, even when printing years in the
range 0-9999.

       Mark

bug#21903: date->string duff ISO 8601 negative years

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Zefram <zefram@fysh.org> writes:
>>
>>> The date->string function from (srfi srfi-19), used on ISO 8601 formats
>>> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>>>
>>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>>> scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
>>> $1 = "-4714-11-24T12:00:00Z"
>>>
>>> The date in question, the JD epoch, is 24 November 4714 BC (in the
>>> proleptic Gregorian calendar).  In ISO 8601 format, that year is properly
>>> represented as "-4713", not "-4714", because ISO 8601 uses the AD era
>>> exclusively.  4714 BC = AD -4713.
>>
>> I agree that this is definitely a bug, but I'm nervous about deviating
>> from the SRFI-19 reference implementation, and therefore probably from
>> most other implementations of SRFI-19, in this way.
>
> Also see my comments here:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21904#17
>
> which mention that ISO 8601 apparently requires that the sender and
> receiver agree ahead of time whether an extended format will be used, in
> which case a sign is *always* required, even when printing years in the
> range 0-9999.

Since writing this, I've discovered that the SRFI-19 reference
implementation's formatting of negative years is very badly broken.  For
example, when the year is -2, it prints "00-2".  Guile's behavior was
similarly broken for a short time, after I applied upstream fixes.

Since the current behavior of SRFI-19 and Guile is so clearly broken in
the case of negative years, I'm no longer concerned with maintaining
compatibility with SRFI-19 here.  I also feel more urgency to apply a
fix.

So, I went ahead and implemented your recommended behavior, in commit
a58c7abd72648f77e4ede5f62a2c4e7969bb7f95 on the stable-2.2 branch.

I'm closing this bug now, but please reopen if appropriate.

     Thanks,
       Mark