Message 104269 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	pr0gg3d
Recipients	Alexander.Belopolsky, aht, amaury.forgeotdarc, djc, hodgestar, pr0gg3d, zooko
Date	2010-04-26.19:56:15
SpamBayes Score	0.0003952835
Marked as misclassified	No
Message-id	<1272311778.24.0.223320391827.issue6280@psf.upfronthosting.co.za>
In-reply-to

Content
I thinks that isn't a so easy decision to take. And there are some other issues, imho: 1. timegm function is not specified by any standard (POSIX). The portable way (setting TZ, calling mktime, restore TZ) is a pure hack (could not work in future multithreaded environments). 2. if we want to strictly follow the time.h definition from POSIX standards, the timegm function should be kept away from time module (as now). 3. timegm seems to have some issues on mingw32. 4. Solaris doesn't come with the timegm function out-of-the-box. We could give up at this point.

I thinks that isn't a so easy decision to take.

And there are some other issues, imho:

1. timegm function is not specified by any standard (POSIX). The portable way (setting TZ, calling mktime, restore TZ) is a pure hack (could not work in future multithreaded environments).
2. if we want to strictly follow the time.h definition from POSIX standards, the timegm function should be kept away from time module (as now).
3. timegm seems to have some issues on mingw32. 
4. Solaris doesn't come with the timegm function out-of-the-box.

We could give up at this point.

History
Date	User	Action	Args
2010-04-26 19:56:18	pr0gg3d	set	recipients: + pr0gg3d, zooko, amaury.forgeotdarc, djc, hodgestar, aht, Alexander.Belopolsky
2010-04-26 19:56:18	pr0gg3d	set	messageid: <1272311778.24.0.223320391827.issue6280@psf.upfronthosting.co.za>
2010-04-26 19:56:16	pr0gg3d	link	issue6280 messages
2010-04-26 19:56:15	pr0gg3d	create