Bug in Time module, or in my understanding?

[Joshua J. Kugler]

I am getting results like these with the time module:

%S')))
1173610800 %S')))
1173610800

'2007-03-11 03:00:00'

I know it probably has something to do with daylight savings, but how can I
get back out that which I put in? The times concerned are all standard
time, so how can I keep the time module from asserting its belief that I
want to convert to daylight savings?

Incidentally, it only happens with times on 2007-03-11 from 02:00:00 to
02:59:59, and not with time data from past years.

Thanks for any pointers!

j

 

[Paul Boddie]

I am getting results like these with the time module:

'2007-03-11 03:00:00'

This is quite a nice test case, actually.

I know it probably has something to do with daylight savings, but how can I
get back out that which I put in? The times concerned are all standard
time, so how can I keep the time module from asserting its belief that I
want to convert to daylight savings?

Well, I think that if you inspect the result of strptime, you'll see
that the last element of the time "tuple" - in fact, the tm_isdst
member of a time "structure" - is set to -1:
(2007, 3, 11, 3, 0, 0, 6, 70, -1)

What is likely to happen when such results are passed to mktime is
that the underlying library function will use its discretion in
determining whether daylight savings time is in operation or not.

Incidentally, it only happens with times on 2007-03-11 from 02:00:00 to
02:59:59, and not with time data from past years.

This suggests that the timezone database is being used to provide the
results. In fact, you can override the behaviour of mktime by
constructing time tuples or structures with other values for the last
element or tm_isdst respectively:
1173574800.0

By asserting tm_isdst as being 0, the usual apparent interval between
the times is preserved.

Paul

 

[Joshua J. Kugler]

Well, I think that if you inspect the result of strptime, you'll see
that the last element of the time "tuple" - in fact, the tm_isdst
member of a time "structure" - is set to -1:

(2007, 3, 11, 3, 0, 0, 6, 70, -1)

What is likely to happen when such results are passed to mktime is
that the underlying library function will use its discretion in
determining whether daylight savings time is in operation or not.

That sounds about right.

By asserting tm_isdst as being 0, the usual apparent interval between
the times is preserved.

I'll do that. This isn't so much about DST vs. non-DST (as I may be putting
values in here that were recorded during DST), but in this case it was just
trying to get the same value out that I had put in.

Thanks for the pointers!

j