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