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 lemburg
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.17:45:14
SpamBayes Score 0.0
Marked as misclassified No
Message-id <4D9B5516.8090606@egenix.com>
In-reply-to <1302016972.68.0.428520064904.issue2736@psf.upfronthosting.co.za>
Content
Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
> 
> 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.

IMHO, the whole concept of DST is broken, but that's not our fault :-)

Ditching the concept just because it is known to fail for
one hour out of 8760 you have in a typical year doesn't really
warrant breaking the "practicality beats purity" guideline.

Otherwise, we'd have to ditch the date support in the datetime module
too: after all, Feb 29 only exists every 4 years (well, most of the
time) - and that's one day out of 1461 in those 4 years, so an
even worse ratio :-)

And I'm not even starting to talk about ditching the concept
of Unix ticks to begin with, as a result of having leap seconds
causing POSIX ticks values not matching (real) UTC ticks.

In reality, all these things hardly ever matter and if they do,
users will either know that they have to make conscious decision,
simply don't care or decide not to care.

BTW: A "timestamp" usually refers to the combination of date and
time. The time.time() return value is "seconds since the Epoch".
I usually call those values "ticks" (not sure whether it's standard
term of not, but always writing "seconds since Epoch" wasn't an
option either ;-)).

Date/time is fun, isn't it ?
History
Date User Action Args
2011-04-05 17:45:15lemburgsetrecipients: + lemburg, tim.peters, ping, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov, Jay.Taylor
2011-04-05 17:45:15lemburglinkissue2736 messages
2011-04-05 17:45:14lemburgcreate