Time zone changing while Win app is running

[CM]

Although there is an answer to my concern posted on Stack Overflow[1],
I thought I'd run this by the Python group to just get a read on it,
since it strikes me as a concern.

To summarize the issue: In an application, I have been using Python's
datetime module to get the current time. But it seems that, at least
with Windows (XP), whatever time zone your computer is set to when you
start the application, that's what datetime will use--the time zone
will *not* be updated in the application when you update it manually
with Windows. So, if you change the time zone (say, after traveling
with your laptop), all datetimes will be incorrect as compared to your
system clock.

The S.O. page has an answer that uses ctypes and Kernel32's
GetLocalTime, and I've found I could do that, though it seems it would
require me to substitute this for all uses of Python's datetime...and
that is not a happy consideration at all. If I'm not using datetime,
I am not using dateutil, not doing the same kind of date math, tons of
rewriting... Not good.

I haven't thought things through too well yet, but I was thinking I
could get the correct system time via this ctypes based approach and
then take that and turn it into a Python datetime to preserve all the
benefits of datetime, but even that is going to be a lot of work for
this corner case.

Are things regarding this issue basically as I've understood them? I
hope not.

[1] http://stackoverflow.com/questions/4360981/make-python-respond-to-windows-timezone-changes)

 

[Steven D'Aprano]

To summarize the issue: In an application, I have been using Python's
datetime module to get the current time. But it seems that, at least
with Windows (XP), whatever time zone your computer is set to when you
start the application, that's what datetime will use--the time zone will
*not* be updated in the application when you update it manually with
Windows. So, if you change the time zone (say, after traveling with
your laptop), all datetimes will be incorrect as compared to your system
clock.

I am not the maintainer of the datetime module, but based purely on what
you have said, I would consider that a bug. I suggest you report it as an
issue on the Python bug tracker.

 

[CM]

I am not the maintainer of the datetime module, but based purely on what
you have said, I would consider that a bug. I suggest you report it as an
issue on the Python bug tracker.

Thanks, I submitted an issue about it. On 2.7.3, on Windows, it's
easy to demonstrate:

(Actual time = 2:40pm; tz = Eastern U.S.)

import datetime
print datetime.datetime.now()

2013-04-03 14:40:03.124000 <---- RIGHT

(Now change time zone to UTC, for example. Now clock reads 6:41pm.)

import datetime
print datetime.datetime.now()

2013-04-03 14:41:13.124000 <---- WRONG
^

 

[CM]

2013-04-03 14:41:13.124000 ? ? <---- WRONG
? ? ? ? ? ? ? ? ? ?^

(That carrot is supposed to be pointing to the 4 in 14, which should
be 18.)

 

[Terry Jan Reedy]

I don't. Do you really want every time function slowed by
re-initializing the timezone?

I do believe that time.tzget can now be make to work now on Windows, and
that would be a proper tracker issue.

Thanks, I submitted an issue about it. On 2.7.3, on Windows, it's
easy to demonstrate:

(Actual time = 2:40pm; tz = Eastern U.S.)

2013-04-03 14:40:03.124000 <---- RIGHT

(Now change time zone to UTC, for example. Now clock reads 6:41pm.)

Without a restart, this is a no=op.

2013-04-03 14:41:13.124000 <---- WRONG

As I said on the issue, passing a tz arg to now() will give the answer
for any timezone on earth. A user-friendly app displaying times should
let users choose.

 

[CM]

I don't. Do you really want every time function slowed by
re-initializing the timezone?

It depends; do you know what re-initializing entails and how costly
that would be? I don't.

The way I was thinking of it is, if the documentation for
datetime.datetime.now() is (to begin), "Return the current local date
and time." ...then, at least in the cases in which one changes one's
system timezone during a running Python instance*, the docs are just
not accurate for this method.

(*which is not such a corner case given laptops that travel with us
across them--often this timezone crossing is fundamental to one's work
with that laptop)

I do believe that time.tzget can now be make to work now on Windows, and
that would be a proper tracker issue.

Can you elaborate on how this would help my case?

Without a restart, this is a no=op.

Whoops, thanks; I just copied and pasted it twice.

As I said on the issue, passing a tz arg to now() will give the answer
for any timezone on earth. A user-friendly app displaying times should
let users choose.

Are you saying that the app should require that the user enter their
current time zone into the whenever they change time zones (in
addition to their changing it in the Windows system clock)? And then
using that tz in every call to datetime.datetime.now()?

Thanks.