> FWIW, I think gaining adoption is the problem. When addressing a
> problem whose solution will never touch an end-user, as you say it's
> best to follow even a flawed standard. In this case though, it will
> touch the user, and so, it must be decided which is easier - to stray
> from the flawed standard or explaining the adherence to a undesirable
> syntax to the user. Personally, I'll stray... a "/" for a range is
> simply unintuitive and I couldn't explain otherwise to a user that
> doesn't know about or value the ISO standard...
Why would it touch the user? The sane thing to do with both dates and
date ranges is to present them to the user in a reasonable localized
format. "January 25th, 2009", rather than "2009-01-25". The is
particularly obvious when you get into the full date+time formats:
"January 25th, 2009 at 3:15 P.M.", rather than "2009-01-25T15:15:00".
Not to mention the fact that it may or may not (depending on the
application and the audience) be appropriate to convert or display
time zone information.
If a user needs to know the exact representation, then a few things
are true: First, they have the expertise to learn what this format
means. Second, they have a reason to want to do so, because their
work requires precision. Third, they have a reason to appreciate that
more formal standard representations look a little different from
"normal" representations, precisely because they must be less
In short: If a user has no need or desire to see "strange"
standardized formats, there is no need to show those formats to them.
If they do have such a need or desire, they will be happy so long as
the format is reasonable, unambiguous, and expressive enough to meet