Bugs item #1646728, was opened at 2007-01-28 21:21
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.fromtimestamp fails with negative fractional times
Initial Comment:
The datetime.fromtimestamp() function works fine with integer timestamps and
positive fractional timestamps, but fails if I pass a negative fractional
timestamp. For example:
>>> import datetime
>>> datetime.datetime.fromtimestamp(-1.05)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: microsecond must be in 0..999999
It should return the same result as datetime.fromtimestamp(-1) -
timedelta(seconds=.5).
The same bug can be triggered in datetime.utcfromtimestamp().
I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-07 10:17
Message:
Logged In: YES
user_id=6380
Originator: NO
Thanks! I'm skipping these tests on Windows now.
Committed revision 54209.
Georgbot, would you be so kind... :-)
----------------------------------------------------------------------
Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-03-07 02:34
Message:
Logged In: YES
user_id=1200846
Originator: NO
Hello, I'm user of Windows (Now building Python2.5 with VC6)
I heard localtime() can only handle positive time_t on windows,
so datetime.fromtimestamp() also fails for negative value.
>>> datetime.datetime.fromtimestamp(-1.05)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: timestamp out of range for platform localtime()/gmtime()
function
>>> datetime.datetime.fromtimestamp(-1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: timestamp out of range for platform localtime()/gmtime()
function
I'll attach workaround for unittest. Probably there is better way
skip this test on non-negative platform though :-)
Index: Lib/test/test_datetime.py
===================================================================
--- Lib/test/test_datetime.py (revision 54194)
+++ Lib/test/test_datetime.py (working copy)
@@ -1428,9 +1428,17 @@
def test_negative_float_fromtimestamp(self):
# The result is tz-dependent; at least test that this doesn't
# fail (like it did before bug 1646728 was fixed).
+ try:
+ self.theclass.fromtimestamp(-1)
+ except ValueError: # cannot handle negative value
+ return
self.theclass.fromtimestamp(-1.05)
def test_negative_float_utcfromtimestamp(self):
+ try:
+ self.theclass.utcfromtimestamp(-1)
+ except ValueError: # cannot handle negative value
+ return
d = self.theclass.utcfromtimestamp(-1.05)
self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58,
950000))
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-06 13:45
Message:
Logged In: YES
user_id=849994
Originator: NO
Not from me, no Windows around.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-06 13:34
Message:
Logged In: YES
user_id=6380
Originator: NO
That's too bad. More details?
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-06 13:15
Message:
Logged In: YES
user_id=849994
Originator: NO
Though, the new tests seem to fail on Windows (I noticed that only after
backporting, since most other buildbot failures were due to the cmp/key
problem in setup.py).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-06 12:59
Message:
Logged In: YES
user_id=6380
Originator: NO
Georgbot backported this to 2.5.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-06 10:50
Message:
Logged In: YES
user_id=6380
Originator: NO
Committed revision 54167.
I'm leaving this open until it's been backported to the 2.5 branch.
----------------------------------------------------------------------
Comment By: James Henstridge (jhenstridge)
Date: 2007-03-05 19:03
Message:
Logged In: YES
user_id=146903
Originator: YES
I just tried the patch, and can confirm that it fixes the problem with
datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the
patch looks correct.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-05 13:38
Message:
Logged In: YES
user_id=6380
Originator: NO
Attached is a fix. If this is to your liking I'll check it in.
File Added: datetime.patch
----------------------------------------------------------------------
Comment By: James Henstridge (jhenstridge)
Date: 2007-03-05 05:23
Message:
Logged In: YES
user_id=146903
Originator: YES
The problem seems to be in datetime_from_timestamp() from
datetimemodule.c. It should probably be checking to see whether the
microseconds value it calculates is negative, and adjust "timet" and "us"
accordingly if so.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-02 11:05
Message:
Logged In: YES
user_id=6380
Originator: NO
Looks like a bug in the conversion from floats to ints. Anyone care to
track it down more precisely?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
