[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in r85441. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Mark, Do you agree that conditions mentioned in msg109329 and msg109340 are never triggered? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Reopening to consider removing a special case in days_before_year(..). After r82128, year cannot be = 0. -- stage: committed/rejected - commit review status: closed - open Added file: http://bugs.python.org/file17869/issue9005c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Similarly, it appears that
if (*m 1 || *m 12) {
--*m;
normalize_pair(y, m, 12);
++*m;
/* |y| can't be bigger than about
* |original y| + |original m|/12 now.
*/
}
in normalize_y_m_d(int *y, int *m, int *d) is a dead branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9005
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I raised this issue on python-dev and Guido said OK. See [Python-Dev] Year 0 and year 10,000 in timetuple, http://mail.python.org/pipermail/python-dev/2010-June/100682.html I am attaching a commit ready patch which contains a few more test cases and a NEWS entry. I don't think there is a need to mention this in documentation, but at some point I would like to be able to write that dt.utctimetuple() is equivalent to dt.astimezone(timezone.utc).timetuple(), but at the moment it is not quite so. See issue 9004. -- resolution: - accepted stage: patch review - commit review Added file: http://bugs.python.org/file17728/issue9005a.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Added file: http://bugs.python.org/file17729/issue9005b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in r82128. -- stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- keywords: +patch Added file: http://bugs.python.org/file17722/issue9005.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Note that a recently closed issue 7150 similarly tightened up datetime operations by making out of range dates raise OverflowError rather than produce non-sensible result. This case is not a clear cut, but now with timezone.utc available in datetime module, I believe users should be encouraged to use t.astimezone(timezone.utc) to produce UTC time. If timetuple is required the later can be converted using timetuple() method. Idelally, t.utctimetuple() should be deprecated in favor of more explicit t.astimezone(timezone.utc).timetuple(). Unfortunately the two expressions are subtly different because t = datetime.max.replace(tzinfo=timezone.min) t.astimezone(timezone.utc) Traceback (most recent call last): File stdin, line 1, in module OverflowError: date value out of range -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9005] Year range in timetuple
New submission from Alexander Belopolsky belopol...@users.sourceforge.net: Current datetime.timetuple() implementation goes out of its way to support edge cases that produce timetuples beyond the naive datetime range: t1 = datetime.min.replace(tzinfo=timezone.max) t2 = datetime.max.replace(tzinfo=timezone.min) print(t1.utctimetuple()) time.struct_time(tm_year=0, tm_mon=12, tm_mday=31, tm_hour=0, tm_min=1, tm_sec=0, tm_wday=6, tm_yday=366, tm_isdst=0) print(t2.utctimetuple()) time.struct_time(tm_year=1, tm_mon=1, tm_mday=1, tm_hour=23, tm_min=58, tm_sec=59, tm_wday=5, tm_yday=1, tm_isdst=0) The last result is particularly troublesome because it may crash time.asctime on POSIX compliant systems. See Issue #6608. tm_year is described in help(time) as 4-digit year suggesting range of [1000, ]. Most C libraries support even smaller ranges. -- assignee: belopolsky components: Extension Modules messages: 107907 nosy: belopolsky, mark.dickinson priority: normal severity: normal stage: needs patch status: open title: Year range in timetuple type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
