Martin v. Löwis wrote:
> Christian Tismer wrote:
>> 1. create a file
>> 2. get it's os.path.getmtime()
>> 3. change your time zone
>> 4. get os.path.getmtime again
>>
>> compare - the time stamps are different.
>> Change the time zone back, and they are identical, again.
>
> Just to add an importa
Christian Tismer wrote:
> 1. create a file
> 2. get it's os.path.getmtime()
> 3. change your time zone
> 4. get os.path.getmtime again
>
> compare - the time stamps are different.
> Change the time zone back, and they are identical, again.
Just to add an important detail here: I assume
you did no
Alexander Schremmer wrote:
There are several issues involved in implementing such a patch, though.
One is that you need to do it twice: once for Win9x, and once for
NT+, because you have to use Unicode file names on one system, and
ANSI file names on the other.
>
>
>>Right - the q
On Sun, 15 Jan 2006 20:23:39 +0100, "Martin v. Löwis" wrote:
>>> There are several issues involved in implementing such a patch, though.
>>> One is that you need to do it twice: once for Win9x, and once for
>>> NT+, because you have to use Unicode file names on one system, and
>>> ANSI file names
Christian Tismer wrote:
> Does it mean that msvcrt does extra magic to modify the existing
> correct UTC entries?
Mostly, yes. For FAT, the system does also some conversion.
Those conversions I don't fully understand,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/
Hi Martin,
>> Is there a way to circumvent this problem, or am I missing something?
>> If this is not the expected behavior, then it might make sense
>> to find a patch.
>
> I have meant to work on a patch for several years now. I would like to
> drop usage of msvcrt's stat(3), and instead implem
Christian Tismer wrote:
> Is there a way to circumvent this problem, or am I missing something?
> If this is not the expected behavior, then it might make sense
> to find a patch.
I have meant to work on a patch for several years now. I would like to
drop usage of msvcrt's stat(3), and instead imp
Phillip J. Eby wrote:
> Windows doesn't store UTC timestamps, at least not on older FAT filesystems
> and maybe not even on NTFS. Changing Python won't help. :)
Windows definitely stores UTC timestamps on NTFS, in units of 100ns
since Jan 1, 1601.
Regards,
Martin
__
[Christian Tismer]
> Hi Python developers,
>
> today I got a complaint from the python.de IRC channel
> about os.path.getmtime and time zone.
>
> How to produce the weird behavior:
>
> 1. create a file
> 2. get it's os.path.getmtime()
> 3. change your time zone
> 4. get os.path.getmtime again
>
> c
At 02:37 AM 1/15/2006 +0100, Christian Tismer wrote:
>I assumend the value would be in UTC, but it is obviously not.
>
>Is there a way to circumvent this problem, or am I missing something?
>If this is not the expected behavior, then it might make sense
>to find a patch.
Windows doesn't store UTC
Hi Python developers,
today I got a complaint from the python.de IRC channel
about os.path.getmtime and time zone.
How to produce the weird behavior:
1. create a file
2. get it's os.path.getmtime()
3. change your time zone
4. get os.path.getmtime again
compare - the time stamps are different.
C
11 matches
Mail list logo
