The gmtime function in the calendar module would be
much more logical to have in the time module, since it
manipulates tm tuples and unix timestamps, which the
other functions in time do, but no other functions in
calendar.

Related to bug #697983

Logged In: YES 
user_id=33168

The gmtime function is in time, not calendar.  Did you mean
the opposite that you believe gmtime should be in calendar?
  gmtime comes from the C version which is the purpose of
time, to expose C functions.

Logged In: YES 
user_id=31435

I expect the OP meant the calendar.timegm() function.

Logged In: YES 
user_id=357491

OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide 
the same functionality?  Or is the desire to have it because  it specifies the 
epoch as 1970-01-01?

Logged In: YES 
user_id=31435

mktime() interprets its argument as local time; timegm() as 
UTC.  Generally speaking,

time.mktime(time.localtime())

returns int(time.time()), and so does

calendar.timegm(time.gmtime())

The OP appears to be right that the time module doesn't 
have an "inverse" for time.gmtime() in this sense.  Then 
again, the time functions inherited from C are generally a 
twisted thicket.

Logged In: YES 
user_id=357491

Well then, is there any desire to bother to make this happen?  Or is this just 
a "I hope someone likes this idea enough to implement it" instance in which 
case this should probably be made an RFE.

Logged In: YES 
user_id=31435

Sorry, I don't have time to give to this.  It's certainly not a 
bug report <wink>.

Logged In: YES 
user_id=80475

Erland, I propose that you close this one.

The time and calendar API's have been around for a good 
while and changes would have a negative impact, even if 
they have some logic to it.

The new datetime module for Py2.3 makes the time module 
obsolete; is organized logically; and should meet most of 
your needs.

Logged In: YES 
user_id=11375

Closing per Tim's suggestion.