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
--
http://mail.python.org/mailman/listinfo/python-list
