I hate to be so blunt about it, but perhaps we are settling on the
wrong solution. After all, what good is a date standard that won't allow
you to specify perfectly legitimate dates? Getting involved with the ISO
standards process through ANSI is, I would imagine, no trivial operation.
If you don't believe me take a look at http://www.ansi.org/finitnl.html
(and that assumes your organization is a member or willing to become
one). Certainly it is not as easy as participating in defining the
Dublin Core <grin>. I think Robin Martherus' suggestion to extend ISO
8601 as required would be a reasonable compromise while we await a
standard that is more flexible. So long as we specify that is what we are
doing and why I think that is a workable solution. As Robin says, the
delimiters should help prevent parsers from choking entirely (although
who knows what they would do with a year beyond 4 digits, or a negative
number). Misha?
Roy Tennant
On Fri, 25 Jul 1997, Misha Wolf wrote:
> Robin Martherus wrote (appended) about the lack of support in ISO 8601 for:
> (a) years before year 0000, and (b) years after year 9999.
>
> The latter would seem easier to solve, through the use of additional digit(s).
> The former is more of a challenge.
>
> ISO is a federation of national member bodies. ISO standards come up for
> revision every five years. ISO 8601 is currently being revised. If you want
> it changed, the best thing is to get involved in the current revision through
> your national member body (ANSI, if you're US-based) and/or through discussion
> on the tz (time zone) mailing list. To join the list, send the word
> "subscribe" (without the quotes) to <[log in to unmask]>.
>
> Misha
>
> > Hi there,
> >
> > I have been lurking on this list for about a year now and would like to get
> > some input from you regarding ISO8601. My company wants to use the Dublin
> > Core tags in one of our products. We would also like to use ISO8601 for
> > storing dates in the DC.date tag as well as other date related fields but
> > find the profile is lacking in the year area because it is limited to the
> > years from 0000 to 9999.
> >
> > I know that Misha has already mentioned that this is a shortcoming and that
> > those of us who need years outside of that range should use a diferent
> > standard.
> >
> > What I would like to hear from you is what you recommend we use. We have
> > been discussing the possiblity of using a modified ISO8601 by not limiting
> > the year to 4 digits but using as many digits as are needed to represent
> > the year. This should not become a problem while parsing because the
> > various date/time elements already have delimiters seperating them.
> >
> > This would allow archeologists, peleontologists, geologists, etc to use the
> > standard for recording dates well before 0000. Even librarians have works
> > written by Plato and others well before the year 0000.
> >
> > If ISO8601 is not the solution for us what should we use?
> >
> > Thanks in advance,
> >
> > Robin Martherus
> >
> > --------------------------------------------------------------------
> > Robin Martherus [log in to unmask]
> > Verano, Inc. phone 415/237-0207
> > 411 Clyde Avenue fax 415/237-0211
> > Mountain View, CA 94043
> > --------------------------------------------------------------------
> >
> >
>
> ------------------------------------------------------------------------
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Reuters Ltd.
>
>
|