Trash spec: directory size cache

[Alexander Larsson]

On mån, 2013-04-15 at 16:28 +0200, Bastien Nocera wrote:
> 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".
> "

Its not less well defined, its just vastly less complicated (no spec
needed, no parser, no whatever). Less moving parts means less chance for
errors.

For instance, if someone forgot the add the Z in the timestamp the
string is immediately non-utc and things will not work in some
timezones.