Author belopolsky
Recipients Jay.Taylor, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, lemburg, mark.dickinson, ping, pitrou, r.david.murray, steve.roberts, tim.peters, tomster, vivanov, vstinner, werneck
Date 2011-04-05.18:06:34
SpamBayes Score 2.04419e-06
Marked as misclassified No
Message-id <>
Let me state my position on this issue once again.  Converting datetime values to float is easy.   If your dt is a naive instance representing UTC time:

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

If your dt is an aware instance:

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

These recipes are easy to adjust for your application needs.  One application may want millisecond or microsecond ticks, another might want to carry subsecond presision in a separate integer, third may want to avoid timestamps before 1970 or after 2038 or ignore microseconds altogether.  No matter what a hypothetical datetime.epoch() will provide, most of applications will need to add a line or two to its code to serve their needs. Applications that will use dt.epoch() naively without thinking what dt represents (say local or UTC) will be buggy.

The only related feature that I think is missing from datetime module is the ability to obtain local time as an aware datetime instance and to convert a naive datetime instance assumed to represent local time to an aware one.

This is the subject of #9527, but there is a resistance to adding that feature.
Date User Action Args
2011-04-05 18:06:37belopolskysetrecipients: + belopolsky, lemburg, tim.peters, ping, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov, Jay.Taylor
2011-04-05 18:06:37belopolskysetmessageid: <>
2011-04-05 18:06:35belopolskylinkissue2736 messages
2011-04-05 18:06:34belopolskycreate