timezones and time_t

[MrBlueSky]

Hi,
I've got a Python application that (as well as lots of other stuff!)
has to translate time_t values into strings in the TZ of the users
choice. Looking at the Python Library Reference, I can see no platform
independent way of setting the TZ that time.localtime() returns -
tzset() is marked as only available on Unix and that is indeed the
case.

Is there really nothing "shipped as standard"? I'm using Python 2.4.3
on Windows XP.

If not, what's the de-facto standard... pytz?

Ta!

John

 

[Eyal Lotem]

Hi,
I've got a Python application that (as well as lots of other stuff!)
has to translate time_t values into strings in the TZ of the users
choice. Looking at the Python Library Reference, I can see no platform
independent way of setting the TZ that time.localtime() returns -
tzset() is marked as only available on Unix and that is indeed the
case.

Is there really nothing "shipped as standard"? I'm using Python 2.4.3
on Windows XP.

If not, what's the de-facto standard... pytz?

Ta!

John

All of the timezone stuff in the standard C/Python libraries is very badly
named and the use of implicit 'TZ' variables in various functions without a
hint in their __doc__ is also annoying.

Basically, I recommend just doing your own TZ translation:
time.asctime(time.gmtime(time.time() + TZOFFSET))


My name recommendations for alternative time interface (t=float-time_t,
tt=timetuple, local_ prefix=function converts via tz parameters):

time.time -> time.gmt
Return the current GMT as a float time_t

time.local_t -> time.
Return the current Local Time as a float time_t
If argument is given, convert it to local format.

time.asctime -> time.str
Return the given time_t as a string. No conversions done.

time.ctime -> time.local_str
Remove in favor of: time.str(time.local_t)

time.mktime -> time.t_of_tt
time.gmtime -> time.tt_of_t
time.localtime -> Remove in favor of: time.tt_of_t(time.local_t)

These functions above will prevent a lot of confusion, because you are
forced to either use: time.local_t or time.gmt, and thus you are aware of
what the time_t you are using means. When you use time.str no implicit
conversion takes place as in time.ctime, and confusion is avoided.

Do you think this is worth a PEP?

 

[MrBlueSky]

Thanks for the reply. Unfortunately, a simple "+offset" type solution
isn't really accurate enough for the kind of scenario I'm looking at.
I'm often dealing with different timezones with DST changeovers on
different dates or even different times of day! So I need
industrial-strength timezone handling!

Wrt your naming conventions... sorry, I'm a newbie to Python so not
really qualified to comment. But what's a PEP?