Trash specification, version 0.1
Dave Cridland
dave at cridland.net
Mon Aug 30 17:24:34 EEST 2004
On Mon Aug 30 15:06:51 2004, Mikhail Ramendik wrote:
> > How could it not be? Its the number of seconds since the epoch
> (00:00:00
> > UTC, January 1, 1970). Its what the posix time() function
> returns. It is
> > also how ctime, mtime and atime are stored in the structure
> returned
> > from stat(). So, its not like its an uncommon format for file
> times.
>
> So you would prefer a hexadecimal representation of the epoch
> number, in
> UTC?
>
>
Surely octal... No, I'm kidding. ASCII decimal, please, if you're
going to go that route. Or pure binary if you want to shave off a
little more by not having to parse ASCII.
> (I now tend to think both UTC and local time are needed, to satisfy
> automatic filters on local time. But we need to reach a consensus on
> what time(s) are needed and in what format, before I write this
> into the
> spec).
>
>
You only need a fully qualified localtime. (If you want localtimes at
all. I think they're more useful in this instance, but that's just my
opinion.)
So:
2004-08-30D15:11:00T+01:00
(Which gives, easily, both my subjective time - a little after 3pm -
and can be used to get to UTC quickly, too.)
Implementations may choose to provide only UTC with:
2004-08-30D14:11:00T-00:00
As per RFC3339 - that's saying "14:11 in UTC, but I don't know or
care what the local time was.", as opposed to:
2004-08-30D14:11:00T+00:00
which says "14:11 in my local time, which is (or was at that time)
the same as UTC" - so you'd use this format in winter in the UK,
amongst other places.
IMHO:
- SHOULD use local time.
- If not using local time, MUST use -00:00 suffix as per RFC3339.
Oh, should we try to support a desktop variant of RFC748 in this
specification?
Dave.
More information about the xdg
mailing list