<div dir="ltr">2008/9/15 David Faure <<a href="mailto:dfaure@trolltech.com">dfaure@trolltech.com</a>> <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Tuesday 08 April 2008, Karl Chen wrote: > > Hi, this is a comment about > <a href="http://www.ramendik.ru/docs/trashspec.html" target="_blank">http://www.ramendik.ru/docs/trashspec.html</a>, > <a href="http://www.freedesktop.org/wiki/Specifications/trash-spec" target="_blank">http://www.freedesktop.org/wiki/Specifications/trash-spec</a> . > > 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. Indeed. 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.</blockquote><div> 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 Time". I think that supporting only UTC would be simpler to implements than supporting Local Offsets or both. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Alexander, do you? I don't want to start writing out stuff that would break your implementation :-) </blockquote></div> 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? -- Andrea Francia <a href="http://andreafrancia.blogspot.com/">http://andreafrancia.blogspot.com/</a> </div>