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.15:22:51
SpamBayes Score 9.75819e-08
Marked as misclassified No
Message-id <1302016972.68.0.428520064904.issue2736@psf.upfronthosting.co.za>
In-reply-to
Content
MAL> Since most of the datetime module was inspired by mxDateTime,
MAL> I wonder why [ticks()/gmticks()] were left out. (msg75411)

"""
The datetime module intended to be an island of relative sanity.
Because the range of dates "timestamps" can represent varies across
platforms (and even "the epoch" varies), datetime doesn't even try to
produce timestamps directly -- datetime is more of an alternative to
"seconds from the epoch" schemes. Because datetime objects have
greater range and precision than timestamps, conversion is
problem-free in only one direction. It's not a coincidence that
that's the only direction datetime supplies ;-)
""" - Tim Peters
 
http://bytes.com/topic/python/answers/522572-datetime-timestamp

I will also add that fromtimestamp() is not invertible in the presence of DST.  That's why mxDatetime.ticks() takes a DST flag making it effectively a multi-valued function.  Note that naive users, who just want to pass datetime values to an OS function expecting a float, most likely will not have means of properly obtaining DST flag.
History
Date User Action Args
2011-04-05 15:22:52belopolskysetrecipients: + 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 15:22:52belopolskysetmessageid: <1302016972.68.0.428520064904.issue2736@psf.upfronthosting.co.za>
2011-04-05 15:22:52belopolskylinkissue2736 messages
2011-04-05 15:22:51belopolskycreate