Trash local time zone issue

[André Gillibert]

The Freedesktop Trash specification 0.7 seems to imply that the DeletionDate MUST be stored in YYYY-MM-DDThh:mm:ss format in the local time zone, though it's not stated with the normative RFC 2119 MUST word.

<http://www.ramendik.ru/docs/trashspec.html> specifies:
>  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. The value type for this key is “string”.

Moreover the example doesn't respect this format:
> DeletionDate=20040831T22:32:08

I assume that YYYY-MM-DDThh:mm:ss is the only allowed format.
Storing deletion dates in local time zone formats raises issues:

1) In countries using DST, local date & times in this format are ambiguous when the clock jumps backward.
Local times without explicit time offset from UTC are unreliable.
2) When moving a medium (e.g. USB key) around the world, it may be connected to computers of different time zones, making their interpretation of date & times incorrect.
3) When moving a laptop around the world, a business man may adjust his computer time zone to the local zone.
4) Any file sharing system concurrently accessed by remote machines may also raise the issue.

I see several solutions to this problem.

1) Require (or at least allow) times to be expressed as absolute UTC times as YYYY-MM-DDThh:mm:ssZ
2) Or, require (or at least allow) times to be expressed as local time + offset to UTC as YYYY-MM-DDThh:mm:ss+HH:MM

The latter is the most informative as it contains information about the zone in which the file has been deleted. It's also very readable by users who don't want to deal with UTC times.
However, it's a bit harder to parse or generate and isn't easily sorted by string comparison functions.

For backwards compatibility, the YYYY-MM-DDThh:mm:ss form should be accepted (as input) by implementations, and treated as a local datetime.