I'm guessing there is an easy way to do this but I keep going around
in circles in the documentation.

I have a time stamp that looks like this (corresponding to UTC time):

start_time = '2007-03-13T15:00:00Z'

I want to convert it to my local time.

start_time = time.mktime(time.strptime(start_time, '%Y-%m-%dT%H:%M:
00Z'))
start_time -= time.timezone

This was working fine now, but if I do it for a date next week (such
as March 13th in the above example), it breaks because my local time
moves to daylight savings time this weekend. So my time is now off by
an hour. I'm guessing if I try this next week it will work okay
because time.timezone will be give a different value next week - is
that correct?

Is there a direct way to convert that timestamp in UTC to a local
time stamp that will always work?

TIA,
Dave

davelist@mac.com wrote:

I'm guessing there is an easy way to do this but I keep going around
in circles in the documentation.
>
I have a time stamp that looks like this (corresponding to UTC time):
>
start_time = '2007-03-13T15:00:00Z'
>
I want to convert it to my local time.
>
start_time = time.mktime(
time.strptime(start_time, '%Y-%m-%dT%H:%M:00Z')
)

Here, strptime in this case will probably produce a time whose
daylight saving time (DST) status will be undecided, although I've
done some tests with glibc which suggests that the native (unused by
Python) strptime produces non-DST-affected times for both the given
date and for a date one month later in my time zone (contrary to what
one might expect). Then, mktime is called, but this may apply various
time zone magic to treat the supplied time as a local time, not a GMT/
UTC time - this seems to be an artifact of the way mktime is defined
and implemented in various standards.

Do this to see what I'm talking about:

time.mktime(time.gmtime(0))

Unless you have GMT/UTC as your time zone, the above may well not
produce zero as its result. Similar tests in C behave identically.

start_time -= time.timezone

So, here you've applied a time shift in order to hopefully go from GMT/
UTC to local time. Given my observations of mktime, I'm inclined to
believe that you've time shifted beyond local time, but the principle
seems reasonable. See below for more discussion.

This was working fine now, but if I do it for a date next week (such
as March 13th in the above example), it breaks because my local time
moves to daylight savings time this weekend. So my time is now off by
an hour. I'm guessing if I try this next week it will work okay
because time.timezone will be give a different value next week - is
that correct?

The value of time.timezone should remain the same. In your time tuple/
structure (produced by strptime) there's a field called tm_isdst (it's
the value in the last position) which governs when DST applies. If DST
applies you need to use time.altzone instead of time.timezone to guide
conversions between local time and GMT/UTC.

Is there a direct way to convert that timestamp in UTC to a local
time stamp that will always work?

I think you have to test tm_isdst and then apply time.timezone (if
tm_isdst is 0) or time.altzone (if tm_isdst is 1) in the way you've
attempted. But as I said, you have to be careful with mktime, since
tests both with Python and directly against glibc suggest that it
considers the time to be local, and a subsequent call to localtime
won't actually give you a different hour, minute and second than that
provided in the supposedly GMT/UTC time.

Paul

P.S. There's more to come on this topic, since I'm trying to improve
time zone support on time tuples/structures. It's an arcane business,
however, and I'm still trying to make sense out of the behaviour of
various library functions.