Alexander Belopolsky wrote:
On Wed, Jun 16, 2010 at 1:37 PM, Brett Cannon <brett@python.org> wrote: ..
The only improvement I could see, would be to move calendar.timegm() to the time module, since that's where it belongs (keeping an alias in the calendar module, of course).
That should definitely happen at some point.
This is discussed in Issue 6280 <http://bugs.python.org/issue6280>. There are several issues with this proposal:
1. According to help(time),
""" The Epoch is system-defined; on Unix, it is generally January 1st, 1970. The actual value can be retrieved by calling gmtime(0). """
Current calendar.gmtime implementation ignores this. The solution to this, may be to change help(time), though.
2. Current calendar.gmtime supports float values for hours, minutes and seconds in timedelta tuple. This is probably an unintended implementation artifact, but it is relied upon even in stdlib. See http://bugs.python.org/issue6280#msg107808 .
I think you have this mixed up: I was suggesting to move calendar.timegm() to the time module, not the non existing calendar.gmtime() :-) If you're looking for a portable implementation in C that doesn't mess with TZ hacks, have a look at the mxDateTime sources. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/