fd.o trash specification - DeletionDate timezone
andrea at andreafrancia.it
Mon Sep 15 07:52:09 PDT 2008
2008/9/15 David Faure <dfaure at trolltech.com>
> On Tuesday 08 April 2008, Karl Chen wrote:
> > Hi, this is a comment about
> > http://www.ramendik.ru/docs/trashspec.html,
> > http://www.freedesktop.org/wiki/Specifications/trash-spec .
> > The current Trash spec (version 0.7) says:
> > * The key "DeletionDate" contains the date and time when the
> > file/directory was trashed. The date and time are to be in the
> > YYYY-MM-DDThh:mm:ss format (see RFC 3339). The time zone should
> > be the user's (or filesystem's) local time.
> > I applaud the choice of YYYY-MM-DDThh:mm:ss over the despicable
> > ctime() format.
> > One suggestion I have: use UTC and/or specify the timezone.
> > Files may live in the trash can across daylight savings changes.
> > A laptop or filesystem's local timezone can change as the user
> > moves his laptop or removable media across timezone boundaries.
> > Network file systems can be in different timezones from the
> > client.
> > I believe that using the local timezone without specifying the
> > timezone may cause problems.
> Although this is just for informing the user when he/she's browsing
> the trash, this could be a minor source of bugs.
> > In the language of RFC 3339, the current format of the
> > DeletionDate field is "4.4. Unqualified Local Time". I propose
> > that the format of DeletionDate be changed to "4.2. Local Offsets"
> > (e.g. 1996-12-19T16:39:57-08:00) or "4.1. Coordinated Universal
> > Time" (e.g. 1996-12-20T00:39:57Z), i.e. standard RFC 3339.
> I agree with this proposal.
I agree, but the specification should specify how to interpret a
DeletionDate written as "Unqualified Local Time".
At the moment it does not specify if the time should be interpret as user's
time or filesystem's time.
I also propose that:
- A implementation MUST be able to read trashinfo files also if the
DeletionDate is an "Unqualified Local Time".
- A implementation COULD NOT write the DeletionDate as "Unqualified Local
I think that supporting only UTC would be simpler to implements than
supporting Local Offsets or both.
> Alexander, do you?
> I don't want to start writing out stuff that would break your
> implementation :-)
If a new version of the specification is to be released I suggest to make
clearer the fact that (for the volume trash directories) the path are
relative to the $topdir and not the parent of the trash directory.
There is not a chance to have a issue tracking system and possibly a source
control system for these Spec?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg