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 Arfrever, belopolsky, jcea, khenriksson, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, vstinner
Date 2011-06-24.21:21:50
SpamBayes Score 7.7595826e-07
Marked as misclassified No
Message-id <>
> there is no easy way to convert it into "seconds since the epoch"

Ah yes, it remembers me that Alexander rejected my .totimestamp() patch (#2736) because he considers that "Converting datetime values to float is easy":

(dt - datetime(1970, 1, 1)) / timedelta(seconds=1)

I still think that this formula is *not* trivial, and must be a builtin method. For example, the formula is different if your datetime object if an aware instance:

(dt - datetime(1970, 1, 1, tzinfo=timezone.utc)) / timedelta(seconds=1)

When do you need to convert file timestamps to epoch? If we use datetime in os.stat output, we should also accept it as input (e.g. for os.utime).

> any broken-down time has issues of time stamp ordering in
> the duplicate hour of switching from DST to normal time

I understand that it is an issue of the datetime module. Can it be solved, or is there a design issue in the module?

> time zone support is flaky-to-nonexistent in the datetime module

Python 3.3 has now a builtin implementation of fixed timezones, but yes, there are still things to be improved (e.g. support timezone names like "CET").


I don't have a strong opinion on this issue, I just wanted to know why datetime cannot be used for this issue.
Date User Action Args
2011-06-24 21:21:51vstinnersetrecipients: + vstinner, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, nadeem.vawda, Arfrever, r.david.murray, rosslagerwall, khenriksson
2011-06-24 21:21:51vstinnersetmessageid: <>
2011-06-24 21:21:51vstinnerlinkissue11457 messages
2011-06-24 21:21:50vstinnercreate