```Oh... Yes.. I speak up from fractional seconds! The second as time atom? No-
No.

I think I was clear on my feeling about this. Did I not flood this list with
more than one diatribe on units of time measurement, write about Babylonian
Barleycorns or 1/72 time degree (actively used in Jewish time measures, which
even has the concept of a "moment" as 1/76 a Barleycorn, eg. 5/114 sec.), TAI
(caesium-133) and what's on the horizon..???

On Thu, 14 Feb 2013 21:00:24 -0500, Byrd, Donald A. wrote
> Thanks for the detailed explanation, Ray. I thought calling EDTF a
> "profile" of 8601 just meant that redundant ways to represent the same
> information would be removed; I didn't realize the scope of what could
> be represented might be reduced. But I still have some questions.
>
> First, you said that no one spoke up for retaining fractional seconds,
> but the first URL you give is a message from Edward Zimmermann in which
> he says: "8601 uses hh:mm:ss.fff where fff are milliseconds.. Why not
> hh:mm:ss
> where ss are rational seconds. e.g. ss including decimal fractions
> without restriction, e.g. allowing for times such as 12:21:44.5 and
> 12:59:59.1001". So he _did_ speak up for fractional seconds! In fact,
> he asked for any number of decimal places -- which is actually what
> 8601 allows, not just milliseconds (i.e., exactly 3 decimal places),
> according to two descriptions of it I have.
>
> And second, I have the impression that EDTF Level 0 can express
> virtually everything 8601 can express _except_ fractional seconds
> (though with fewer ways to express a lot of things). If I'm right, it
> seems like a real mistake to remove fractional seconds in EDTF Level 0.
> Especially since Levels 1 and 2 don't add them back in! Of course, as
> you say, there will be a follow-up opportunity to propose more
> features, but even so.
>
> --DAB
>
>
> > Hi Don - Yes, maximum precision is one second. It wasn't always so, early
> > drafts supported fraction of second in the same manner as ISO 8601.
> >
> > It was never the intention of this effort to fully support 8601. It tries
to
> > be a profile/extension of/to ISO 8601, As it says in the abstract:
> >
> > "ISO 8601 describes a large number of date/time formats. On one hand some
of
> > these formats are redundant and/or not very useful; to reduce the scope
for
> > error and the complexity of software, it seems worthwhile to restrict the
> > supported formats to a smaller set. On the other hand, there are a number
of
> > date and time format conventions in common use that are not included in
ISO
> > 8601; it seems worthwhile to normalize these."
> >
> > And so, early drafts had quite a lot of features that did not make the
cut.
> > We went through a process of questioning each feature, and if nobody spoke
> > up for a feature, it was removed.
> >
> >
> > (For "fraction of a second", see
> > <http://listserv.loc.gov/cgi-bin/wa?
A2=ind1103&L=DATETIME&P=R5149&I=-3&X=048
> > 09F159E636F2A03&Y=rden%40loc.gov>
> > http://listserv.loc.gov/cgi-bin/wa?
A2=ind1103&L=DATETIME&P=R5149&I=-3&X=0480
> > 9F159E636F2A03&Y=rden%40loc.gov where I asked
> >
> >
> > "For time, is hour:minute:second sufficient, or do we need to support
> > fraction of a second?"
> >
> >
> > Nobody responded, so it was removed.
> >
> >
> > That's not to say that fraction of second is not a useful feature, it
simply
> > means that nobody who has participated in this round of the development of
> > the spec found it useful.  There will be a follow-up opportunity to
propose
> >
> >
> > Ray
> >
> >
> >
> >> -----Original Message-----
> >
> >> From: Discussion of the Developing Date/Time Standards
> >> Sent: Thursday, February 07, 2013 11:41 AM
> >> Subject: [DATETIME] Precision better than one second
> >>
> >> I may be blind, but as far as I can tell from both the text and the BNF,
> >> EDTF's maximum precision is one second. OK, That's considerably more
> >> limited than ISO 8601, which allows unlimited precision! For example,
> >> "13:10:30,7" is 30.7 sec. after 13:10, with precision of 1/10 second. And
> >> some people seem actually to be using 8601 with millisecond resolution --
> >> for example, see the Joda.org website:
> >
> >>  <http://joda-time.sourceforge.net/cal_iso.html>
> > http://joda-time.sourceforge.net/cal_iso.html .  I assume that this is
> >
> >> either my mistake or a mistake in the EDTF proposal? Surely it's not a
> > good
> >> idea to add any further limitations to 8601.
> >
> >>
> >
> >> --Don
> >
> >>
> >
> >>
> >
> >
>
> --
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics
> Visiting Scientist, Research Technologies
> Indiana University Bloomington

--

Edward C. Zimmermann, NONMONOTONIC LAB/BSn
http://www.ibu.de/IB_Engine
Umsatz-St-ID: DE130492967
```