DateTime Documentation Inconsistancy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DateTime |
Fix Released
|
Low
|
Unassigned |
Bug Description
There are inconsistencies in the DateTime module documentation, DateTime.txt, and it also appears that the DateTime docstrings are inconsistent. The ones that bit me were regarding float/int/long returning seconds since the epoch not days since 1901, though there may be others particualary regarding single argument constructors and any talk of 1901...
The DateTime.txt file in the DateTime module says at the end of the file:
> int(aDateTime)
>
> Convert to an integer number of days since Jan. 1, 1901 (gmt)
However dateTime.py says it returns the nuber of seconds since the epoch
> def __int__(self):
> """Convert to an integer number of seconds since the epoch (gmt)"""
> return int(self.millis() / 1000)
affects: | zope2 → datetime |
Changed in datetime: | |
status: | Fix Committed → Fix Released |
There is another discrepancy between the documentation and the implentation. I'm currently working with Zope 2.9.4
"If the function is invoked with three or more numeric arguments, then the first is taken to be an integer year, the second is taken to be an integer month, and the third is taken to be an integer day. If the combination of values is not valid, then a DateTimeError is raised. Two-digit years are assumed to be in the twentieth century."
However, this is not the case as _correct_year() is called:
def _correctYear(year):
# Y2K patch.
if year >= 0 and year < 100:
# 00-69 means 2000-2069, 70-99 means 1970-1999.
if year < 70:
year = 2000 + year
else:
year = 1900 + year
return year
ie. 68, 01, 01 becomes 2068-01-01 which may cause surprises. As neither mx.DateTime. DateFrom and datetime.date perform any black magic assumptions for the century I suggest this also be the case for Zope's DateTime. Of course, it might simply be time to start refactoring it to make use of datetime / mx.DateTime.