[Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime

[SourceForge.net]

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 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