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 2 1336
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
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 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
37 posts
views
Thread by jwaixs |
last post: by
|
25 posts
views
Thread by Xah Lee |
last post: by
|
17 posts
views
Thread by Pam Ammond |
last post: by
|
7 posts
views
Thread by jsale |
last post: by
|
30 posts
views
Thread by Franck PEREZ |
last post: by
|
8 posts
views
Thread by digitalorganics |
last post: by
|
2 posts
views
Thread by dfj225 |
last post: by
|
4 posts
views
Thread by Peter J. Bismuti |
last post: by
|
5 posts
views
Thread by Jeff Schwab |
last post: by
| | | | | | | | | | | |