emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#26149: closed (SRFI-19 doc erroneously warns about


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#26149: closed (SRFI-19 doc erroneously warns about Gregorian reform)
Date: Tue, 25 Apr 2017 07:46:03 +0000

Your message dated Tue, 25 Apr 2017 09:44:53 +0200
with message-id <address@hidden>
and subject line Re: bug#26149: SRFI-19 doc erroneously warns about Gregorian 
reform
has caused the debbugs.gnu.org bug report #26149,
regarding SRFI-19 doc erroneously warns about Gregorian reform
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
26149: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26149
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: SRFI-19 doc erroneously warns about Gregorian reform Date: Fri, 17 Mar 2017 23:53:07 +0000
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#26149: SRFI-19 doc erroneously warns about Gregorian reform Date: Tue, 25 Apr 2017 09:44:53 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
On Wed 19 Apr 2017 18:11, Zefram <address@hidden> 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 <address@hidden>
> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]