GNU bug report logs - #21903
date->string duff ISO 8601 negative years

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21903 in the body.
You can then email your comments to 21903 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: bug-guile <at> gnu.org
Subject: date->string duff ISO 8601 negative years
Date: Fri, 13 Nov 2015 14:01:57 +0000

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

Message #8 received at 21903 <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: 21903 <at> debbugs.gnu.org
Subject: Re: bug#21903: date->string duff ISO 8601 negative years
Date: Thu, 20 Apr 2017 01:09:11 +0100

[Message part 1 (text/plain, inline)]

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

[0002-fix-SRFI-19-s-ISO-8601-year-numbering.patch (text/x-diff, attachment)]

Message #11 received at 21903 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Zefram <zefram <at> fysh.org>
Cc: 21903 <at> debbugs.gnu.org
Subject: Re: bug#21903: date->string duff ISO 8601 negative years
Date: Sat, 20 Oct 2018 18:33:31 -0400

Zefram <zefram <at> 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

Message #14 received at 21903 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Zefram <zefram <at> fysh.org>
Cc: 21903 <at> debbugs.gnu.org
Subject: Re: bug#21903: date->string duff ISO 8601 negative years
Date: Sat, 20 Oct 2018 20:40:26 -0400

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

> Zefram <zefram <at> 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

Message #19 received at 21903-done <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Zefram <zefram <at> fysh.org>
Cc: 21903-done <at> debbugs.gnu.org
Subject: Re: bug#21903: date->string duff ISO 8601 negative years
Date: Sun, 21 Oct 2018 00:01:59 -0400

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

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> Zefram <zefram <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.