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

SourceForge.net noreply at sourceforge.net
Wed Mar 21 11:25:59 CET 2007 

Patches item #1667546, was opened at 2007-02-23 23:25
Message generated for change (Comment added) made by gbrandl
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: Georg Brandl (gbrandl)
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: Georg Brandl (gbrandl)
Date: 2007-03-21 10:25

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'm attaching a patch with some corrections of mine. It looks very good
now.

However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can
that be repaired? If not, the tests must be skipped in this case.
File Added: time-1.diff

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-03-20 00:20

Message:
Logged In: YES 
user_id=226443
Originator: YES

File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-03-20 00:19

Message:
Logged In: YES 
user_id=226443
Originator: YES

Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time
zone information to convert local and UMT times to UNIX times. Added tests
and updated the docs.

The usual caveats apply: I'm new to all this, so some things may need
sanity checking.
File Added: tm_gmtoff_zone_timegm_mktimetz.diff

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-03-14 22:43

Message:
Logged In: YES 
user_id=226443
Originator: YES

Looking at this a bit more, it seems like timegm (which is a pretty
desirable function to have) really is as simple as the calendar.timegm
function, as far as I can tell: it just throws time zone information away.
So the timegm implementation in the patches so far is actually wrong (and
broken in the way it attempts to use tm_gmtoff, anyway).

However, it might be nice to have a function which actually interprets
times properly in order to produce a UNIX time. In other words, something
which returns zero for both time.localtime(0) and time.gmtime(0), along
with other times which happen to refer to the epoch but in other time
zones.

I'll upload a fixed patch in the next day or so, hopefully. Sorry for the
noise!

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-12 14:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

The patch looks good so far -- but I'd be comfortable with a few more
tests, for example
for strptime and strftime.

Also, the documentation must be updated for every user-visible change (the
addition
of timegm(), the additional timetuple fields, the now-working (?) %z and
%Z in str[fp]time
and behavior changes).

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 21: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 20: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 17: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 17: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 22: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-08 23: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-08 23: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 00: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 00: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 15: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

More information about the Patches mailing list