mktime() like function to produce GMT?

[Guido van Rossum]

"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?

> 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.

> For things
> like rfc822 date headers this is, of course, completely unnecessary.

And that's where these issues typically come up.

> 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.

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