Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72046

Re: os.stat and time zones

Show key headers only | View raw

On 25May2014 13:47, Nagy László Zsolt <gandalf@shopzeus.com> wrote:
>This might be a silly question. Documentation of os.stat:
>
>>The exact meaning and resolution of the st_atime, st_mtime, and 
>>st_ctime attributes depend on the operating system and the file 
>>system. For example, on Windows systems using the FAT or FAT32 file 
>>systems, st_mtime has 2-second resolution, and st_atime has only 
>>1-day resolution. See your operating system documentation for 
>>details.
>So it says that the meaning is platform dependent.
>
>But here is something interesting. Supposedly, os.stat(fpath).st_mtime 
>and os.path.getmtime(path) return the same thing. The documentation of 
>os.path.getmtime says that it "returns the number of seconds since the 
>epoch". And the time module says that "To find out what the epoch is, 
>look at gmtime(0)". And the documentation of gmtime says that it 
>converts the given value to a struct_time *that is in UTC*.
>
>If the above are true, then as far as I can see, the meaning of 
>st_mtime is NOT platform dependent. It always means the number of 
>seconds elapsed since the epoch in UTC.

You have conflated two things here.

The "offset since the epoch" is a number of seconds since a (platform 
dependent) epoch: the "start of time" for the OS time counters on that system.

It has _nothing_ to do with UTC.

As far as st_atime and friends go, the epoch itself is platform dependent and 
so is the resolution (FAT filesystems having lower precision than might seem 
sane, probably to get a longer time range from a small field).

The field names come from POSIX, which comes from UNIX. The .st_atime etc field 
names are still presented on Windows to make code more portable. But Windows 
has a different epoch (UNIX time starts at the beginning of 1 January 1970; 
that is its "epoch").

The gmtime() function takes the platform dependent offset-from-epoch and gives 
you a struct_time, which has human friendly date and hours/minutes/etc fields.  
These necessarily must be in a timezone, and UTC is a common frame of reference 
and the zone returned by gmtime() ("gmt" means GMT, Greenwich Mean Time, which 
is close to a synonym for UTC).

Between Windows and UNIX, the differences are the resolution and the epoch.

UTC is not platform dependent and not called so by the doco. That also makes it 
a useful zone to pass around in some contexts.

Cheers,
Cameron Simpson <cs@zip.com.au>

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: os.stat and time zones Cameron Simpson <cs@zip.com.au> - 2014-05-26 12:47 +1000

csiph-web