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 vstinner
Recipients belopolsky, ethan.furman, larry, mark.dickinson, r.david.murray, tbarbugli, trcarden, vstinner
Date 2015-07-02.22:55:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1435877745.41.0.166636497448.issue23517@psf.upfronthosting.co.za>
In-reply-to
Content
I'm concerned by this example:

>>> dt = datetime(2015, 2, 24, 22, 34, 28, 274000)
>>> dt - datetime.fromtimestamp(dt.timestamp())
datetime.timedelta(0, 0, 1)

I don't know yet if it should be fixed or not.

If we modify .fromtimestamp(), should we use the same rounding method in datetime constructor? And in datetime.now()/.utcnow()?

I would prefer to keep ROUND_DOWN for .now() and .utcnow() to avoid timestamps in the future. I care less for other methods.

What do you think of this plan?

---

Hum, I don't remember the whole story line of rounding timestamps in Python. Some raw data.

Include/pytime.h of Python 3.5+ has:

typedef enum {
    /* Round towards minus infinity (-inf).
       For example, used to read a clock. */
    _PyTime_ROUND_FLOOR=0,
    /* Round towards infinity (+inf).
       For example, used for timeout to wait "at least" N seconds. */
    _PyTime_ROUND_CEILING
} _PyTime_round_t;

Include/pytime.h of Python 3.4 had:

typedef enum {
    /* Round towards zero. */
    _PyTime_ROUND_DOWN=0,
    /* Round away from zero. */
    _PyTime_ROUND_UP
} _PyTime_round_t;

Include/pytime.h of Python 3.3 and older didn't have rounding.

C files using pytime.h rounding in Python 3.4 (grep -l _PyTime_ROUND */*.c):

Modules/_datetimemodule.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/_testcapimodule.c
Modules/timemodule.c
Python/pytime.c

It is used by 3 mores C files in Python 3.5:

Modules/socketmodule.c
Modules/_ssl.c
Modules/_threadmodule.c

NEAREST was never implemented in pytime.h.

If I recall correctly, there were inconsitencies between the Python and the C implementation of the datetime module. At least in Python 3.5, both implementations should be consistent (even if some people would prefer a different rounding method).

The private pytime API was rewritten in Python 3.5 to get nanosecond resolution. This API is only used by the datetime module to get the current time.

My rationale for ROUND_DOWN was to follow how UNIX rounds timestmaps. As Alexander wrote, UNIX doesn't like timestamps in the future, so rounding towards minus infinity avoids such issue. Rounding issues become more common on file timestamps with filesystems supporting microsecond resolution or event nanosecond resolution.
History
Date User Action Args
2015-07-02 22:55:45vstinnersetrecipients: + vstinner, mark.dickinson, belopolsky, larry, r.david.murray, ethan.furman, tbarbugli, trcarden
2015-07-02 22:55:45vstinnersetmessageid: <1435877745.41.0.166636497448.issue23517@psf.upfronthosting.co.za>
2015-07-02 22:55:45vstinnerlinkissue23517 messages
2015-07-02 22:55:44vstinnercreate