[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:


New changeset 66c88ce30ca2b23daa37038e1a3c0de98f241f50 by Alexander Belopolsky 
in branch 'master':
Closes bpo-28281: Remove year (1-) limits on the weekday() function. (#4109)
https://github.com/python/cpython/commit/66c88ce30ca2b23daa37038e1a3c0de98f241f50


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I submitted Mark's patch unchanged as PR 4109.  If we don't hear from Mark, I 
will address my own comments and merge.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Change by Alexander Belopolsky :


--
pull_requests: +4079
stage: commit review -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Hello Mark, 

Would you be able to prepare a pull request on GitHub for your patch?

Thanks!

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The patch should include an update to documentation.

1. We should probably explain that python -mcalendar does not reproduce the 
output of UNIX cal.  For example, on Mac OS (and various Linux variants): 

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
   1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


but 

$ python3 -mcalendar 1752 9
   September 1752
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

2. We should explain that while the calendar module relies on datetime, it 
implements an infinite calendar with a period of 400 years.

3. A reference should be made to ISO 8601 for our treatment of nonpositive 
years.

Given ISO 8601 and the simplicity of this change, I don't think Raymond will 
insist that we continue imposing datetime-like limits, but I would like to give 
him a chance to renew his objection once the no-limits calendar is documented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Alexander as core developer and the creator of this issue can merge the patch 
after making his review. But first we should make a decision whether it is 
worth to do at all. I'm +0 now. Raymond seems has objections.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Who can merge this patch ?

--
nosy: +matrixise

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
stage: needs patch -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Mark Gollahon]

Mark Gollahon added the comment:

First time patch for CPython.  I followed instructions given by belopolsky and 
added tests.  Please critique.

--
keywords: +patch
nosy: +golly
Added file: http://bugs.python.org/file44917/calendar-no-year-limits.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Okay, if this is specified by ISO 8601 standard, I think we can extend calendar 
below year 1. But the meaning of non-positive years should be documented. And 
maybe even provide a way to customize the representation of year (this is a 
separate issue).

Standard Unix utilities cal and ncal support only years in range 1...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The proposed interpretation of nonpositive years is not arbitrary, it is a 
natural extension of the same formulas that we use for positive years.  On the 
other hand 1- limits are arbitrary.  If we wanted to restrict calendars to 
4-digit years we would limit years to the 1000- range.

Note that interpreting year 0 as 1 BCE is not without a precedent.  ISO 8601 
standard does exactly that with the caveat that "values in the range [] 
through [1582] shall only be used by mutual agreement of the partners in 
information interchange." Furthermore, "an expanded year representation 
[±Y] must have an agreed-upon number of extra year digits beyond the 
four-digit minimum, and it must be prefixed with a + or − sign instead of the 
more common AD/BC (or BCE/CE) notation; by convention 1 BC is labelled +, 2 
BC is labeled -0001, and so on."  See 
 citing ISO 8601:2004 sections 
3.4.2, 4.1.2.4 and Annex B.1.1.

Furthermore, documenting the existing limits is not an easy task.  For example

>>> from calendar import *
>>> cal = TextCalendar(1)
>>> cal.prmonth(1, 1)
 January 1
Tu We Th Fr Sa Su Mo
   1
 2  3  4  5  6  7  8
 9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

displays 6 days in December of 1 BCE as blanks.  Similarly itermonthdays() and 
itermonthdays2() generators yield objects corresponding to these days.  Are 
these days within the calendar limits or not?

Note that I am not proposing to extend the range of the datetime.date objects.  
Doing that would be a much more difficult task, but defining calendars for out 
of range years as those for year % 400 is trivial and much easier than to 
figure out and document the edge behaviors.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Under my proposal year=-1 is 2 B.C. and year 0 is a leap year

We should refuse the temptation to guess (i.e. make up our own arbitrary 
interpretations).   Instead, just document the known limits.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Under my proposal year=-1 is 2 B.C. and year 0 is a leap year

$ ./python.exe -mcalendar 0 2
 February 0
Mo Tu We Th Fr Sa Su
1  2  3  4  5  6
 7  8  9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29

This is the simplest extension and people who require other variants can make 
their own adjustments.  (This suggests that we should probably bring weekday(), 
isleap(), etc. methods to the Calendar class to allow users to override them.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think data range is limited by year 1 due to ambiguity of year -1. Is it 1 
B.D. or 2 years before year 1 (2 B.D.)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> What's the use case for this?

Why did George Mallory climb Mount Everest? "Because it's there."

We have two open issues complaining about calendar behavior for years 1 and 
: #28253 and #26650.  There is also a closed issue #15421 that attempted to 
fix an overflow in the year  only to introduce a silent error.

I don't think there are use cases beyond educational (demonstrating calendar 
periodicity?) or testing, but since several users bothered to report edge case 
bugs, it is probably easier to remove the limits than to properly document them.

Fortunately, extending calendar to arbitrary years does not require climbing 
Mount Everest.  Since the proleptic calendar repeats every 400 years, all we 
need (assuming issue 28253 patch is applied) is to fix the weekday() function 
as follows:

 def weekday(year, month, day):
 """Return weekday (0-6 ~ Mon-Sun) for year (1970-...), month (1-12),
day (1-31)."""
+if not 0 < year < 1:
+year = 2000 + year % 400
 return datetime.date(year, month, day).weekday()

$ ./python.exe -mcalendar 4 12
   December 4
Mo Tu We Th Fr Sa Su
 1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

$ ./python.exe -mcalendar -104 2
   February -104
Mo Tu We Th Fr Sa Su
1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29

We can also treat negative years "properly" so that year 1 is preceded by year 
-1, but I don't think there is any value in this.

--
dependencies: +calendar.prcal() output has a problem
keywords: +easy
nosy: +xiang.zhang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Walter Dörwald]

Walter Dörwald added the comment:

I don't think that's necessary. What's the use case for this?

And if we want to to this, wouldn't it be better to enhance datetime, so that 
this use case is supported too?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +doerwalter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28281] Remove year limits from calendar

[Alexander Belopolsky]

New submission from Alexander Belopolsky:

The calendar module currently relies on datetime for some calculations and is 
therefore restricted to years 1 through .  With exception to some public 
methods that are documented to return datetime.date instances, this dependence 
on the datetime module can be removed.

--
assignee: belopolsky
messages: 277467
nosy: belopolsky, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove year limits from calendar
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com