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

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.

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

This is the same as issue10634

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?

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.