[Tutor] problem with time module
rdm at rcblue.com
Mon Aug 16 08:34:24 CEST 2004
Tim Peters wrote at 19:12 8/15/2004:
> > OK, here's my reasoning. From the doc,
> > "mktime( t)
> > This is the inverse function of localtime(). Its argument is the
> > struct_time or full 9-tuple (since the dst flag is needed; use -1 as the
> > dst flag if it is unknown) which expresses the time in local time, not
> > UTC. ...
> > "
>And it really is an inverse: localtime() takes a timestamp and
>converts to a local struct_time, while mktime() does exactly the
Please forgive me for persisting here, but mktime(t) is not the inverse
function of localtime() in the same precise way that pow(n,2) and sqrt(n)
are inverses of each other (for n >= 0):
>>> from math import sqrt
>>> n = 78.56
>>> print pow(sqrt(n),2)
>>> print sqrt(pow(n,2))
Thus my misunderstanding of the doc.
> > If mktime(t) is the inverse of localtime(), I thought this implied that
> > the floating point number mktime(localtime()) returned would be
> > seconds from the epoch based on my local time. I saw nothing that
> > said that all timestamps are based on UTC (although I can see now
> > that it's a Good Thing they are). I did understand that time() is based
> > on UTC. Therefore I concluded that mktime(localtime()) should be
> > about 7 hours less than time().
>Unfortunately, the time module consists of thin wrappers around the
>pretty miserable time functions defined by the C language. That's why
>"everyone knows" what "seconds from the epoch" <sheesh> means, and
>"everyone knows" too that "seconds from the epoch" means UTC. It
>sucks, but that's life. If it all possible, I'd encourage you to use
>the newer datetime module instead.
Thanks, I'll do that.
And thanks very much for your assistance, Mr. Peters.
More information about the Tutor