Trash spec: directory size cache
Bastien Nocera
hadess at hadess.net
Mon Apr 15 07:28:45 PDT 2013
Em Mon, 2013-04-15 às 14:36 +0200, Alexander Larsson escreveu:
> 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.
How is it any better defined than ISO8601 with the timezone information?
>From g_time_val_to_iso8601():
"
ISO 8601 allows a large number of date/time formats, with or without
punctuation and optional elements. The format returned by this function
is a complete date and time, with optional punctuation included, the UTC
time zone represented as "Z", and the tv_usec part included if and only
if it is nonzero, i.e. either "YYYY-MM-DDTHH:MM:SSZ" or
"YYYY-MM-DDTHH:MM:SS.fffffZ".
"
More information about the xdg
mailing list