By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,097 Members | 1,529 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,097 IT Pros & Developers. It's quick & easy.

Bug in Time module, or in my understanding?

P: n/a
I am getting results like these with the time module:
>>import time
int(time.mktime(time.strptime('2007-03-11 02:00:00', '%Y-%m-%d %H:%M
%S')))
1173610800
>>int(time.mktime(time.strptime('2007-03-11 03:00:00', '%Y-%m-%d %H:%M
%S')))
1173610800
>>time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(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

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ *ID 0xDB26D7CE

Aug 1 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Joshua J. Kugler wrote:
I am getting results like these with the time module:
>import time
int(time.mktime(time.strptime('2007-03-11 02:00:00', '%Y-%m-%d %H:%M:%S')))
1173610800
>int(time.mktime(time.strptime('2007-03-11 03:00:00', '%Y-%m-%d %H:%M:%S')))
1173610800
>time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(1173610800))
'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:
>>time.strptime('2007-03-11 02:00:00', '%Y-%m-%d %H:%M:%S')
(2007, 3, 11, 2, 0, 0, 6, 70, -1)
>>time.strptime('2007-03-11 03:00:00', '%Y-%m-%d %H:%M:%S')
(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:
>>time.mktime((2007, 3, 11, 2, 0, 0, 6, 70, -1))
1173574800.0
>>time.mktime((2007, 3, 11, 2, 0, 0, 6, 70, 0))
1173574800.0
>>time.mktime((2007, 3, 11, 2, 0, 0, 6, 70, 1))
1173571200.0
>>time.mktime((2007, 3, 11, 3, 0, 0, 6, 70, -1))
1173578400.0
>>time.mktime((2007, 3, 11, 3, 0, 0, 6, 70, 0))
1173578400.0
>>time.mktime((2007, 3, 11, 3, 0, 0, 6, 70, 1))
1173574800.0

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

Paul

Aug 1 '07 #2

P: n/a
On Wednesday 01 August 2007 14:45, Paul Boddie wrote:
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:
>>>time.strptime('2007-03-11 02:00:00', '%Y-%m-%d %H:%M:%S')
(2007, 3, 11, 2, 0, 0, 6, 70, -1)
>>>time.strptime('2007-03-11 03:00:00', '%Y-%m-%d %H:%M:%S')
(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

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ *ID 0xDB26D7CE

Aug 1 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.