SF bug 661086: datetime.today() truncates microseconds.
On Windows, it was very common to get microsecond values (out of
.today() and .now()) of the form 480999, i.e. with three trailing
nines. The platform precision is .001 seconds, and fp rounding
errors account for the rest. Under the covers, that 480999 started
life as the fractional part of a timestamp, like .4809999978.
Rounding that times 1e6 cures the irritation.
Confession: the platform precision isn't really .001 seconds. It's
usually worse. What actually happens is that MS rounds a cruder value
to a multiple of .001, and that suffers its own rounding errors.
A tiny bit of refactoring added a new internal utility to round
doubles.
diff --git a/Modules/datetimemodule.c b/Modules/datetimemodule.c
index 2755f72..a64365a 100644
--- a/Modules/datetimemodule.c
+++ b/Modules/datetimemodule.c
@@ -120,6 +120,19 @@
return quo;
}
+/* Round a double to the nearest long. |x| must be small enough to fit
+ * in a C long; this is not checked.
+ */
+static long
+round_to_long(double x)
+{
+ if (x >= 0.0)
+ x = floor(x + 0.5);
+ else
+ x = ceil(x - 0.5);
+ return (long)x;
+}
+
/* ---------------------------------------------------------------------------
* General calendrical helper functions
*/
@@ -1905,12 +1918,7 @@
}
if (leftover_us) {
/* Round to nearest whole # of us, and add into x. */
- PyObject *temp;
- if (leftover_us >= 0.0)
- leftover_us = floor(leftover_us + 0.5);
- else
- leftover_us = ceil(leftover_us - 0.5);
- temp = PyLong_FromDouble(leftover_us);
+ PyObject *temp = PyLong_FromLong(round_to_long(leftover_us));
if (temp == NULL) {
Py_DECREF(x);
goto Done;
@@ -2858,7 +2866,8 @@
datetime_from_timestamp(PyObject *cls, TM_FUNC f, double timestamp)
{
time_t timet = (time_t)timestamp;
- int us = (int)((timestamp - (double)timet) * 1e6);
+ double fraction = timestamp - (double)timet;
+ int us = (int)round_to_long(fraction * 1e6);
return datetime_from_timet_and_us(cls, f, timet, us);
}