This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients brian.curtin, loewis, mark.dickinson, pitrou, tim.golden, vstinner
Date 2012-02-21.16:44:39
SpamBayes Score 6.1381514e-05
Marked as misclassified No
Message-id <1329842680.9.0.903933171971.issue13863@psf.upfronthosting.co.za>
In-reply-to
Content
For some reason that I'm unable to follow right now, fstat in the crt does this dance to obtain st_mtime:
- obtain time stamps using GetFileInformationByHandle
- convert ftLastWriteTime using FileTimeToLocalFileTime to LocalFTime
- convert LocalFTime using FileTimeToSystemTime to SystemTime
- convert SystemTime using __loctotime32_t to st_mtime

Now, SystemTime is broken-down local time, and loctotime32 converts that to "UTC" using an explicit formula taking the *current* time zone into account. This should work correctly, though, as FileTimeToLocalFileTime also takes into account the current time zone.

Anybody analysing this further might want to write a C program that passes explicit time values into this procedure (see Vc/crt/src/fstat.c and dtoxtime.c for the exact source code), to find out what step exactly goes wrong.
History
Date User Action Args
2012-02-21 16:44:40loewissetrecipients: + loewis, mark.dickinson, pitrou, vstinner, tim.golden, brian.curtin
2012-02-21 16:44:40loewissetmessageid: <1329842680.9.0.903933171971.issue13863@psf.upfronthosting.co.za>
2012-02-21 16:44:40loewislinkissue13863 messages
2012-02-21 16:44:39loewiscreate