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. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg