Trash specification, version 0.1
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
> > UTC, January 1, 1970). Its what the posix time() function
> returns. It is
> > also how ctime, mtime and atime are stored in the structure
> > from stat(). So, its not like its an uncommon format for file
> So you would prefer a hexadecimal representation of the epoch
> number, in
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
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
(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:
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:
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.
- 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
More information about the xdg