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 Alexander.Belopolsky
Recipients Alexander.Belopolsky, aht, amaury.forgeotdarc, djc, hodgestar, pr0gg3d, zooko
Date 2010-02-20.21:22:18
SpamBayes Score 1.3438288e-08
Marked as misclassified No
Message-id <1266700940.92.0.749691982395.issue6280@psf.upfronthosting.co.za>
In-reply-to
Content
Francesco,

You have my +1 for implementing both 1 and 2 below.
"""
1. Use timegm(3) function where HAVE_TIMEGM is defined (i have a working patch for it)

2. Implement a more portable timegm function with tzset and mktime where HAVE_MKTIME and 
HAVE_WORKING_TZSET is defined (i have a working patch for it)
"""

I don't think "3. Doing some calculation taking calendar.timegm as example" is a good idea.  IMHO, its is more important that timegm is a proper inverse of gmtime on any given platform than to have the same values produced by timegm across platforms.  If system timegm (or mktime) thinks that 1900 is a leap year, for example, python should not attempt to correct that.  Maybe doing "some calculation" on systems that don't have mktime is a reasonable last resort, but I am not sure it is worth the effort.
History
Date User Action Args
2010-02-20 21:22:22Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, zooko, amaury.forgeotdarc, djc, hodgestar, pr0gg3d, aht
2010-02-20 21:22:20Alexander.Belopolskysetmessageid: <1266700940.92.0.749691982395.issue6280@psf.upfronthosting.co.za>
2010-02-20 21:22:19Alexander.Belopolskylinkissue6280 messages
2010-02-20 21:22:19Alexander.Belopolskycreate