[Top][All Lists]

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

bug#26151: date-year-day screws up leap days prior to AD 1

From: Andy Wingo
Subject: bug#26151: date-year-day screws up leap days prior to AD 1
Date: Tue, 25 Apr 2017 09:57:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

On Sat 18 Mar 2017 02:10, Zefram <address@hidden> writes:

> If I had implemented SRFI-19 myself, without reference to existing
> implementations, I would have implemented astronomical year numbering
> (consistent AD year numbering, extending linearly in both directions),
> as used in ISO 8601.  This is the most conventional year numbering,
> and at a stretch one could read SRFI-19 as implying it, by using some AD
> year numbering and not saying to deviate from that scheme.  But really the
> standard is silent on the issue.  Since the signification of date-year is
> an interoperability issue, this silence is a problem, and it is troubling
> that you and I have reached different interpretations of the standard
> on this point.
> Where did you get the idea to use a non-linear year numbering?  What's
> your opinion of SRFI-19's (lack of) text on this matter?  You should
> consider the possibility of changing your implementation to use the
> conventional astronomical year numbering in this slot.

For what it's worth the "you" in your message refers to "hackers of
yore" ;-) I mean, this code's core was last changed in 2001 by a Guile
maintainer a few generations back.  The fact that it's lasted this long
does indicates that it's generally acceptable, but the fact that you
have found so many bugs indicates that there are parts of it that aren't
so good.  And it's old old code that needs modernizing (proper data
structures, pattern matching, and so on).

What I mean to say is that if there's a more sensible thing to do, we
can do it.

To answer your specific question: would this be an ABI change in some
way, or can we make this change in 2.2?


reply via email to

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