Feature Requests item #697985, was opened at 2003-03-05 08:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-10 09:52 Message: Logged In: YES user_id=11375 Closing per Tim's suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 02:36 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-12 20:49 Message: Logged In: YES user_id=31435 Sorry, I don't have time to give to this. It's certainly not a bug report <wink>. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-29 12:22 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 22:59 Message: 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. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 21:50 Message: 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? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 00:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:46 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
