Time zone changing while Win app is running

Discussion in 'Python' started by CM, Apr 3, 2013.

  1. CM

    CM Guest

    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)
     
    CM, Apr 3, 2013
    #1
    1. Advertising

  2. 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
     
    Steven D'Aprano, Apr 3, 2013
    #2
    1. Advertising

  3. CM

    CM Guest

    On Apr 3, 7:37?am, Steven D'Aprano <steve
    > 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, Apr 3, 2013
    #3
  4. CM

    CM Guest


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


    (That carrot is supposed to be pointing to the 4 in 14, which should
    be 18.)
     
    CM, Apr 3, 2013
    #4
  5. On 4/3/2013 2:46 PM, CM wrote:
    > On Apr 3, 7:37 am, Steven D'Aprano <steve
    > > 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
     
    Terry Jan Reedy, Apr 3, 2013
    #5
  6. CM

    CM Guest


    > >> 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.
     
    CM, Apr 4, 2013
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. NGM
    Replies:
    0
    Views:
    2,365
  2. Ryu

    Time Zone in Windows Time

    Ryu, Sep 15, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    18,478
    madamut
    Feb 11, 2009
  3. =?Utf-8?B?VmluY2UgVmFyYWxsbw==?=

    prevent a postback when moving web parts from zone to zone.

    =?Utf-8?B?VmluY2UgVmFyYWxsbw==?=, Feb 8, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    601
    =?Utf-8?B?VmluY2UgVmFyYWxsbw==?=
    Feb 8, 2006
  4. Ringwraith
    Replies:
    4
    Views:
    971
    Ringwraith
    Jan 27, 2004
  5. Krist
    Replies:
    6
    Views:
    806
    Arne Vajhøj
    May 7, 2010
Loading...

Share This Page