Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 _______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
