[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26149: SRFI-19 doc erroneously warns about Gregorian reform
From: |
Andy Wingo |
Subject: |
bug#26149: SRFI-19 doc erroneously warns about Gregorian reform |
Date: |
Wed, 19 Apr 2017 16:42:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
On Sat 18 Mar 2017 00:53, Zefram <address@hidden> writes:
> The documentation, near the start of the section on SRFI-19, says
>
> ! *Caution*: The current code in this module incorrectly extends the
> ! Gregorian calendar leap year rule back prior to the introduction of
> ! those reforms in 1582 (or the appropriate year in various countries).
> ! The Julian calendar was used prior to 1582, and there were 10 days
> ! skipped for the reform, but the code doesn't implement that.
> !
> ! This will be fixed some time. Until then calculations for 1583
> ! onwards are correct, but prior to that any day/month/year and day of the
> ! week calculations are wrong.
>
> The statements that the code is incorrect in this behaviour are erroneous.
> SRFI-19 itself says
>
> # A Date object, which is distinct from all existing types, represents a
> # point in time as represented by the Gregorian calendar as well as by a
> # time zone.
>
> The code is thus correct in always using the Gregorian calendar in
> date structures. Per ISO 8601 it is also correct in always using
> the Gregorian calendar in string output in that standard's formats.
> SRFI-19 isn't explicit about the calendar used as the basis for the
> other string output formats, but since the formatting proceeds from a
> date structure it seems implied that they should use the same basis as
> the date structure. For string input it is explicit that the parseable
> numeric formats correspond directly to fields of the date structure.
> There is no part of SRFI-19 that looks like it is ever intended to use
> the Julian calendar.
>
> So the code should not be `fixed', and the statements about that and about
> incorrectness should be removed from the documentation. It is sensible to
> keep an explicit statement about the treatment of the Gregorian reform,
> but the decision to use the Gregorian calendar proleptically should be
> credited to SRFI-19 (the standard), not to the code.
This makes sense to me, FWIW.
Andy
- bug#26149: SRFI-19 doc erroneously warns about Gregorian reform,
Andy Wingo <=