Title: Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.6
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, ngie, r.david.murray, terry.reedy
Priority: normal Keywords:

Created on 2012-09-13 19:02 by ngie, last changed 2012-09-13 23:04 by terry.reedy. This issue is now closed.

Messages (10)
msg170453 - (view) Author: Enji Cooper (ngie) * Date: 2012-09-13 19:02
Windows doesn't return sane values for localtime(3) (per POSIX [1]) when
the BIOS is set to the local time (the host is a Win2k8-R2 machine):

$ python -V; python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; date; uname -a
Python 2.6.1
09-13-12 19:56:03
Thu, Sep 13, 2012 11:56:03 AM
CYGWIN_NT-6.1-WOW64 QAQA-ORPTO8B466 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin

This seems to be a conscious design choice on Microsoft's part:

I'll try and follow this up with the POSIX folks or maybe Microsoft, but
for the time being this needs to be documentation as an issue with downstream consumers (perl 5.8.9 also illustrates this issue).
msg170454 - (view) Author: Enji Cooper (ngie) * Date: 2012-09-13 20:15
msg170455 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-13 21:21
It seems to me this is more likely a bug in cygwin and/or the cygwin Python port, since I find it hard to believe our windows users would be putting up with getting incorrect localtime results.
msg170456 - (view) Author: Enji Cooper (ngie) * Date: 2012-09-13 21:37
Except it wasn't built within the Cygwin environment...

$ python -c 'import sys; print sys.version'
2.6.1 (r261:67515, Dec  5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)]
$ ldd `which python` | grep -i ygwin || echo "not cygwin"
not cygwin
msg170457 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-13 21:40
Perhaps that is the problem then: running a non-cygwin python from a cygwin environment?  I don't really know, which is why I added Terry to the nosy list...he's got more Windows experience, though maybe not cygwin experience.  I myself no longer have access to a windows/cygwin box, though I may try setting one up again.
msg170458 - (view) Author: Enji Cooper (ngie) * Date: 2012-09-13 22:11
Ok. Turns out I got this backwards. The BIOS clock is set to UTC (which works with the CentOS install on the same drive) and Windows assumes the clock is set to local time [1]. I'll follow it up with the my $work lab team, but it would be nice if this could be tuned properly to report the proper time according to Windows (even if the bloody clock/tz was wrong to begin with).

msg170459 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-13 22:26
I'm not sure it can be.  Windows is screwed up in the way it handles time.  Last I looked they still didn't support having the BIOS clock set to UTC (but is has been a while since I looked).
msg170460 - (view) Author: Enji Cooper (ngie) * Date: 2012-09-13 22:32
Hahaha... you're right:

$ perl -e 'use POSIX; print strftime("%m-%d-%y %H:%M:%S", localtime)."\n";'; date
09-13-12 23:25:49
Thu, Sep 13, 2012  3:25:49 PM
$ python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; date
09-13-12 23:26:25
Thu, Sep 13, 2012  3:26:25 PM
$ python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; env TZ=utc date
09-13-12 23:27:35
Thu, Sep 13, 2012 10:27:35 PM

Now I've just moved the dang clock ahead 8 hours because the timezone is screwed up (now python assumes UTC, Cygwin assumes local time, and Windows assumes UTC), I guess I'll have to recommend `fixing` our Linux installs to use local time (dog gone Windows).
msg170461 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-13 22:51
OK, I'm going to close this, then.
msg170464 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-09-13 23:04
For future reference:
2.6 is no longer supported except for security issues
The same will soon (a month?) be true of 3.2.
Win2k is no longer supported in 3.3
Date User Action Args
2012-09-13 23:04:22terry.reedysetmessages: + msg170464
2012-09-13 22:51:42r.david.murraysetstatus: open -> closed
resolution: not a bug
messages: + msg170461

stage: resolved
2012-09-13 22:32:32ngiesetmessages: + msg170460
2012-09-13 22:26:38r.david.murraysetmessages: + msg170459
2012-09-13 22:11:19ngiesetmessages: + msg170458
2012-09-13 21:40:57r.david.murraysetmessages: + msg170457
2012-09-13 21:37:52ngiesetmessages: + msg170456
2012-09-13 21:21:44r.david.murraysetnosy: + r.david.murray, terry.reedy, belopolsky
messages: + msg170455
2012-09-13 20:15:47ngiesetmessages: + msg170454
2012-09-13 19:02:47ngiecreate