bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

[Zefram]

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.

-zefram

bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

[Andy Wingo]

On Sat 18 Mar 2017 00:53, Zefram <zefram@fysh.org> 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

[Zefram]

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

Andy Wingo wrote:
>This makes sense to me, FWIW.

Patch attached.

-zefram

[-- Attachment #2: 0001-correct-note-about-Gregorian-reform-in-SRFI-19.patch --]
[-- Type: text/x-diff, Size: 2443 bytes --]

From 444703940983d559935c4dd2a2c89d7888c67119 Mon Sep 17 00:00:00 2001
From: Zefram <zefram@fysh.org>
Date: Wed, 19 Apr 2017 17:08:30 +0100
Subject: [PATCH] correct note about Gregorian reform in SRFI-19

SRFI-19 specifies proleptic use of the Gregorian calendar, so it was
incorrect of the documentation to describe the code as erroneous in
doing so.  Rewrite the caution more neutrally, and move it to the section
about the "date" structure, where it seems most relevant.
---
 doc/ref/srfi-modules.texi | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 95509b2..3d44156 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -2383,17 +2383,6 @@ functions and variables described here are provided by
 (use-modules (srfi srfi-19))
 @end example
 
-@strong{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.
-
 @menu
 * SRFI-19 Introduction::        
 * SRFI-19 Time::                
@@ -2593,6 +2582,16 @@ The fields are year, month, day, hour, minute, second, nanoseconds and
 timezone.  A date object is immutable, its fields can be read but they
 cannot be modified once the object is created.
 
+Historically, the Gregorian calendar was only used from the latter part
+of the year 1582 onwards, and not until even later in many countries.
+Prior to that most countries used the Julian calendar.  SRFI-19 does
+not deal with the Julian calendar at all, and so does not reflect this
+historical calendar reform.  Instead it projects the Gregorian calendar
+back proleptically as far as necessary.  When dealing with historical
+data, especially prior to the British Empire's adoption of the Gregorian
+calendar in 1752, one should be mindful of which calendar is used in
+each context, and apply non-SRFI-19 facilities to convert where necessary.
+
 @defun date? obj
 Return @code{#t} if @var{obj} is a date object, or @code{#f} if not.
 @end defun
-- 
2.1.4

bug#26149: SRFI-19 doc erroneously warns about Gregorian reform

[Andy Wingo]

On Wed 19 Apr 2017 18:11, Zefram <zefram@fysh.org> writes:

> Andy Wingo wrote:
>>This makes sense to me, FWIW.
>
> Patch attached.

Thank you!  Applied.  I adapted the change log message to follow Guile
conventions; it was:

> From 444703940983d559935c4dd2a2c89d7888c67119 Mon Sep 17 00:00:00 2001
> From: Zefram <zefram@fysh.org>
> Date: Wed, 19 Apr 2017 17:08:30 +0100
> Subject: [PATCH] correct note about Gregorian reform in SRFI-19
>
> SRFI-19 specifies proleptic use of the Gregorian calendar, so it was
> incorrect of the documentation to describe the code as erroneous in
> doing so.  Rewrite the caution more neutrally, and move it to the section
> about the "date" structure, where it seems most relevant.

As applied:

    Correct note about Gregorian reform in SRFI-19
    
    * doc/ref/srfi-modules.texi (SRFI-19): SRFI-19 specifies proleptic use
    of the Gregorian calendar, so it was incorrect of the documentation to
    describe the code as erroneous in doing so.  Rewrite the caution more
    neutrally, and move it to the section about the "date" structure, where
    it seems most relevant.

Note capitalization of the summary line and an inclusion of the file and
section/function in the commit message.  I know the file is redundant
but this is how we currently do it.  If you use Emacs and Magit,
pressing "C" (capital) in a Magit diff will add this info to the commit
log for you.

Andy