# [Tutor] problem with time module

Dick Moores rdm at rcblue.com
Mon Aug 16 08:34:24 CEST 2004

```Tim Peters wrote at 19:12 8/15/2004:
>[Dick Moores]
> > 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
>opposite.

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)
78.56
>>> print sqrt(pow(n,2))
78.56

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

Thanks, I'll do that.

And thanks very much for your assistance, Mr. Peters.

Dick Moores

```