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:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%29.aspx

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

1. http://pubs.opengroup.org/onlinepubs/009695299/functions/localtime.html

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.

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

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.

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

1. https://help.ubuntu.com/community/UbuntuTime

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

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

OK, I'm going to close this, then.

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