[Python-bugs-list] Re: mktime fails on specific dates (PR#139)

[guido@CNRI.Reston.VA.US]

> * Guido van Rossum (bugs-py@python.org) [991203 16:38]:
> > > I was comparing dates the other day...
> > > 
> /snippage most what I said/
> > > Possible fixes: 
> > > - time-module sets TZ to UCT before calling mktime
> > > - never use localtime on a machine :)
> > > 
> > > Please look into it or mention it clearly in the docs :)
> > 
> > Not sure what you want us to do.  That local time doesn't exist,
> > so an error is appropriate.  The OverflowError is documented in
> > http://www.python.org/doc/current/lib/module-time.html.
> 
> You don't think it's a silly, unnecessary gotcha? It would be very nice
> to *not* have to write umpteen different versions of a teeny function in
> a teeny proggie to have it work on more than one platform, not to
> mention the necessary "figure-out-what-os-we're-on-today"-logic. Not 
> having to check the source-code for your os to figure out why something dies
> would be nice too :) Side-effect of wrapping the c-functions I guess.

There's no need to know what platform you're on.  Just know that you
may have to catch an exception.  That some platforms don't raise the
exception shouldn't bother you.  Look at it from my side.  I know that
mktime() can return an error.  What's more logical than to translate
that error into an exception in the wrapper?

> Calling timegm() instead of mktime() in time_mktime() in the time-module
> prevents it on FreeBSD at least, as timegm() doesn't care about
> timezones and dst at all...

Of course, since timegm() is supposed to work in GMT (UTC).  If you
look at the C man page, mktime() is supposed to work in local time.
So calling timegm() would be wrong.

I still don't see what I can do to alleviate the pain.  Remember, I
don't create the problem, I just pass it on.  Time manipulation
software is a bitch to write, so like to use the standard (!) C
library where I can.

--Guido van Rossum (home page: http://www.python.org/~guido/)