Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Time zone changing while Win app is running (http://www.velocityreviews.com/forums/t959325-time-zone-changing-while-win-app-is-running.html)

CM 04-03-2013 12:04 AM

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/4...mezone-changes)

Steven D'Aprano 04-03-2013 07:37 AM

Re: Time zone changing while Win app is running
 
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

CM 04-03-2013 06:46 PM

Re: Time zone changing while Win app is running
 
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
^

CM 04-03-2013 06:47 PM

Re: Time zone changing while Win app is running
 

> 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 04-03-2013 09:41 PM

Re: Time zone changing while Win app is running
 
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



CM 04-04-2013 05:05 AM

Re: Time zone changing while Win app is running
 


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



All times are GMT. The time now is 05:02 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.