Datetime and time doesn't update timezone in a running Win app

[cm]

BPO	17627
Nosy	@malemburg, @terryjreedy, @abalkin, @tjguk, @bitdancer, @briancurtin

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-04-03.18:39:11.470>
labels = ['type-bug', 'library']
title = "Datetime and time doesn't update timezone in a running Win app"
updated_at = <Date 2013-04-13.18:27:08.045>
user = 'https://bugs.python.org/cm'

bugs.python.org fields:

activity = <Date 2013-04-13.18:27:08.045>
actor = 'sijinjoseph'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-04-03.18:39:11.470>
creator = 'cm'
dependencies = []
files = []
hgrepos = []
issue_num = 17627
keywords = []
message_count = 5.0
messages = ['185943', '185959', '185961', '186776', '186783']
nosy_count = 8.0
nosy_names = ['lemburg', 'terry.reedy', 'belopolsky', 'tim.golden', 'r.david.murray', 'brian.curtin', 'sijinjoseph', 'cm']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17627'
versions = ['Python 2.7', 'Python 3.4']

[cm]

On Windows (tested on XP), the datetime module (and, as reported online in [1], time module) apparently gets the timezone only when a Python instance first starts, but then never updates the timezone during the life of that Python instance. So, if the user changes the system time zone while an application is running, datetime still uses the time zone that the Python instance started with, and so it is incorrect.

Example, Python 2.7.3:

First, the system time zone is set to Eastern U.S. and the system time shows 14:27.

>>> import datetime
>>> print datetime.datetime.now()
2013-04-03 14:27:43.124000

This is correct, and matches the system clock.

Now user changes time zone on Windows to GMT (and doesn't change the time). Clock now shows the time as 18:29.

>>> print datetime.datetime.now()
2013-04-03 14:29:02.875000
            ^
This is incorrect and doesn't match the time shown on the system clock.

Note: if the user changes the system clock time and NOT the time zone, then datetime updates the time fine.

This has been discussed in a Stack Overflow question, with a proposed workaround[1], but it doesn't fix the fact that this makes datetime incorrect for those that have processes that ought to continue across time zone changes as the user moves.

[1]See accepted answer in particular here: http://stackoverflow.com/questions/4360981/make-python-respond-to-windows-timezone-changes

[terryjreedy]

I am not sure this is a bug, as I don't think it reasonable to expect every time function call to re-initialize the timezone setting. I think you should change this to a request to see if time.tzset can now be made to work on Windows and not unix-only (as documented, when added in 2.3). The second StackOverflow answer by Lentjes suggests that it can for current Python.

datetime.now(tz=None) has an option to pass a timezone for adjusting the output. An user-friendly app can pass a real timezone instead of the default None and give users means to change what tz they want times displayed for, which may or may not be the current local timezone.

[bitdancer]

On linux, if you call time.ctime() before and after changing the system /etc/localtime file, the time will be updated without restarting Python. The same applies to datetime.now().

[sijinjoseph]

This is the same as bpo-10634

Problem is with the Windows CRT implementation of localtime which does not seem to be using updated timezone information.

Can this become an issue with technologies like vMotion which allow Live Migration of virtual servers across data centers in different timezones?

One way to address maybe to somehow reset the CRT timezone structures on Windows prior to a call to localtime. Does this seem like a good approach? Is the issue worth pursuing?

[sijinjoseph]

Some more links discussing similar issues
http://www.sourceware.org/bugzilla/show_bug.cgi?id=154 - tzset not called frequently enough by localtime() and friends

http://stackoverflow.com/questions/12150651/library-code-for-dynamically-reloading-the-usr-share-zoneinfo-database - Workaround in linux for reloading timezone info

http://msdn.microsoft.com/en-US/library/90s5c885(v=vs.100).aspx - Microsoft CRT documentation for _tzset function, which can be called to reset timezone info.

Another possible fix, could be to add an overload for the functions to force reloading of the timezone info.

[RobertDeRose]

This isn't only a Windows issue, this happen on Linux as well. Current platform is Ubuntu Jammy running 3.10.6 and changing the system timezone is not reflected in a running python application.

Simple Example:

Using the following packages for assistent in getting the OS timezone and setting the local tz

• dateutil: https://pypi.org/project/python-dateutil/
• tzlocal: https://pypi.org/project/tzlocal/

from datetime import datetime
from time import sleep
from tzlocal import reload_localzone, get_localzone_name
from dateutil.tz import tzlocal
from os import environ


while True:
    now = datetime.now(tzlocal())
    print(now, now.tzname(), get_localzone_name(), environ.get("TZ", None))
    sleep(1)
    reload_localzone()

Output:

2023-10-02 19:28:28.046596+00:00 GMT Africa/Abidjan None
2023-10-02 19:28:29.060294+00:00 GMT Africa/Abidjan None
/root/apollo-wirama-driver/.venv/lib/python3.10/site-packages/tzlocal/utils.py:43: UserWarning: Timezone offset does not match system offset: -14400 != 0. Please, check your config files.
  warnings.warn(msg)
2023-10-02 19:28:30.072880+00:00 GMT America/New_York None
2023-10-02 19:28:30.388293+00:00 GMT America/New_York None