Trash spec: directory size cache

Alexander Larsson alexl at redhat.com
Mon Apr 15 05:36:56 PDT 2013


On mån, 2013-04-15 at 14:25 +0200, Ryan Lortie wrote:
> hi,
> 
> On 2013-04-15 13:43, Alexander Larsson wrote:
> > On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
> >> No strong objections to turning it into unix-timestamp-in-UTC though.
> >
> > NOOOO! The timestamp timezone of a mtime is undefined, and may be
> > different from the actual timezone of the computer doing the stat()
> > call, for instance for NFS mounts. There is no reason whatsoever to do
> > anything to the value returned from stat, as all we do with it is
> > compare it to a later stat value. Any kind of timezone conversion on it
> > will not help and may hurt.
> 
> The kernel time is in UTC...

The kernel will report whatever time_t value was sent over the network
via the NFS protocol. Whether this is UTC or not depends on the server
setup and OS. But sure, if what you mean by "unix-timemstamp-in-UTC" is
"whatever value the kernel gave you in stat()" then that is fine. Just
don't ever try to do anything on that value that depends on the timezone
of the NFS client.

This is exactly where using a string for time makes things tricky. You
need to parse the string, and its easy to accidentally pick some API
that assumes that the string is in local timezone rather than UTC, and
thus get things wrong. If the file just lists a time_t integer value it
is less likely that things go wrong when you compare it with the
stat().st_mtime value.




More information about the xdg mailing list