Subject: bug#21903: closed (Re: bug#21903: date->string duff ISO 8601 negative years)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 21 Oct 2018 04:03:01 +0000

Your bug report

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

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
21903: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21903
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#21903: date->string duff ISO 8601 negative years
From: Mark H Weaver <[email-masked]>
To: Zefram <[email-masked]>
Cc: [email-masked]
Date: Sun, 21 Oct 2018 00:01:59 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Mark H Weaver <[email-masked]> writes:

> Mark H Weaver <[email-masked]> writes:
>
>> Zefram <[email-masked]> 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

Subject: date->string duff ISO 8601 negative years
From: Zefram <[email-masked]>
To: [email-masked]
Date: Fri, 13 Nov 2015 14:01:57 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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