Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #42616 > unrolled thread

Time zone changing while Win app is running

Back to article view | Back to comp.lang.python

Contents

  Time zone changing while Win app is running CM <cmpython@gmail.com> - 2013-04-02 17:04 -0700
    Re: Time zone changing while Win app is running Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 07:37 +0000
      Re: Time zone changing while Win app is running CM <cmpython@gmail.com> - 2013-04-03 11:46 -0700
        Re: Time zone changing while Win app is running CM <cmpython@gmail.com> - 2013-04-03 11:47 -0700
        Re: Time zone changing while Win app is running Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-03 17:41 -0400
          Re: Time zone changing while Win app is running CM <cmpython@gmail.com> - 2013-04-03 22:05 -0700

#42616 — Time zone changing while Win app is running

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)

[toc] | [next] | [standalone]

#42639

On Tue, 02 Apr 2013 17:04:12 -0700, CM wrote:

> 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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#42695

On Apr 3, 7:37 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 02 Apr 2013 17:04:12 -0700, CM wrote:
> > 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.

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
                   ^

[toc] | [prev] | [next] | [standalone]

#42696

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

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

[toc] | [prev] | [next] | [standalone]

#42706

On 4/3/2013 2:46 PM, CM wrote:
> On Apr 3, 7:37 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> On Tue, 02 Apr 2013 17:04:12 -0700, CM wrote:
>>> 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 don't. Do you really want every time function slowed by 
re-initializing the timezone?

>> I suggest you report it as an issue on the Python bug tracker.

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.)
>
>> 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

Without a restart, this is a no=op.

>> print datetime.datetime.now()
> 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.

--
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#42736

> >> I am not the maintainer of the datetime module, but based purely on what
> >> you have said, I would consider that a bug.
>
> 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?

> > (Now change time zone to UTC, for example.  Now clock reads 6:41pm.)
> >> import datetime
>
> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web