This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, mark.dickinson
Date 2010-06-16.03:57:05
SpamBayes Score 0.018474994
Marked as misclassified No
Message-id <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
In-reply-to
Content
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=10000, 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, 9999].  Most C libraries support even smaller ranges.
History
Date User Action Args
2010-06-16 03:57:07belopolskysetrecipients: + belopolsky, mark.dickinson
2010-06-16 03:57:07belopolskysetmessageid: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
2010-06-16 03:57:06belopolskylinkissue9005 messages
2010-06-16 03:57:05belopolskycreate