mktime() like function to produce GMT?

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> "M.-A. Lemburg" <mal at lemburg.com> writes:
> 
> > Guido van Rossum wrote:
> > >
> > > "M.-A. Lemburg" <mal at lemburg.com> writes:
> > > > The last short sentence pretty nicely covers up the problems with timegm()
> > > > :-) "POSIX algorithm" means that leap seconds are not accounted for.
> > >
> > > And what's wrong with that?  The Unix time is just as much an
> > > *encoding* of time values as any other.  Few clocks in the world are
> > > accurate enough to care about leap seconds.  The rest of us
> > > occasionally synchronize with a master clock.  I don't care about leap
> > > seconds and never will.
> >
> > Nothing's wrong with that... it's just that on platforms that use a
> > leap seconds aware standard, you'll get strange timezone
> > offsets when comparing ticks (Unix time values) for local time and
> > the ones calculated using the POSIX timegm() function.
> 
> Do you know of any platforms that use leap seconds?

Linux libc5 and WinXX don't by default... don't know about the others,
but the portable time lib distributed by

	ftp://elsie.nci.nih.gov/pub/

does with proper zoneinfo files.

POSIX.1 explicitely states not to use leap seconds,
ANSI was a bit fuzzy about the definition and since UTC does use
leap seconds, at least some people have come up with proper routines
to deal with them. Quote from the tzcode pacakge available from
the FTP site above:

"""
*       This package is already part of many POSIX-compliant hosts,
        including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun.
"""

So all those platforms could probably use leap seconds in their time
implementations (you'd have to recompile the zoneinfo files with
zic -L to reenable the leap second information).

> > I would assume that astronomers and other people interested in
> > absolute time do care about these subtle differences.
> 
> Of course, but they wouldn't be using the C library's time functions
> for their calculations.

See above.

> > For things
> > like rfc822 date headers this is, of course, completely unnecessary.
> 
> And that's where these issues typically come up.

Sure, but there are people who do care... that's why I put the
note up there.

BTW, any chance of getting the C API timegm() into the time module
on those platforms where it is available and have your function
as replacement on those that don't ?

> > Here a nice pointer with lots of information on the subject:
> >
> >       http://www.bldrdoc.gov/timefreq/glossary.htm
> 
> Too much to read :-(
> 
> > [BTW, could it be that you didn't see the smiley in my reply :-]
> 
> I saw it, but I had no idea what you meant by it.  Still don't.

The intention was a mild notice about why the algorithm becomes
so simple when not considering leap seconds -- I didn't have
any intention to put your approach into some bad light. In fact,
it is exactly this kind of discussion I wanted to avoid...
didn't work, though; I should probably have used the TML
wink tag instead.

Cheers,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                            Y2000: 240 days left
Business:                                      http://www.lemburg.com/
Python Pages:                 http://starship.python.net/crew/lemburg/