Trash specification, version 0.1

[Dave Cridland]

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.