Douglas said:

> One of our targets is to come up with a better alternative 
> than ISO 8601 because it "has problems".  However I've never 
> really seen a list of what _exactly_ its problems are.  Maybe 
> we could collectively constuct a list of all the things we 
> don't like about ISO 8601 to help focus where improvements 
> are needed and to also act as a check list for any potential 
> solution...?
> 
> So I'll start...
> * 8601 dates may contain characters that can't be used in a 
> file or directory name (eg. the forward-slash - e.g. you 
> can't use an 8601 date range in a directory name like 
> "Photos_2005-05-01/2005-05-03"

This may well be true, but I'm really not sure we should interpret it as
something that is "wrong" with ISO8601, or regard it as a requirement
for any other candidate date format. After all, ISO8601 is designed to
be a format for representing dates/times, not for constructing directory
names. ;-) I think we could construct similar criticisms of other
DCMI-recommended schemes (e.g. I can't use the string "text/html" as a
directory name, but MIME types do their job as indications of the format
of a digital object OK).

> * The 8601 Standard contains a large number of possible 
> permutations so any program that attempts to consume and 
> understand 8601 dates will need to be very sophisticated - 
> this may be eaiser if there were a number of well-known 
> profiles to limit the scope for any particular type of date 
> (eg. single date, date range, indefinite date,...)
>
> * Newer versions (2000, 2004) of the 8601 Standard have added 
> extensions like expanded years (more than 4 digits) and 
> implied dates (like circa), but these are only available by 
> "mutual agreement" which means if you use them they aren't 
> "compliant" with most other systems

Right, so we might conceptualise our task as specifying one or more
encoding schemes/datatypes which do indeed serve as explicit indicators
of "mutual agreement" on such things.

Pete