Print

Print


I'd say that the main tradeoffs involved in whether to add any feature 
to a standard are:
1. PRO: may make the standard potentially useful to more people
2. PRO OR CON: increase or decrease compatibility with existing standards
3. CON: make the standard more complex, so harder for programmers to 
handle and harder for users to understand
4. CON: harder to come up with syntax and semantics for

In this case, since we know some people really are using fractional 
seconds with ISO 8601, #2 definitely supports adding them to EDTF. #3 
and #4 are the arguments against, but #4 is a non-issue, since the 8601 
syntax is consistent with EDTF as it stands. And I think #3 is pretty 
weak. Speaking from many years of experience as a programmer, software 
architect, and user-interface designer, it's easy for a programmer to 
handle the 8601 syntax.

Overall, I think the balance is strongly in favor of adding fractional 
seconds back in.

--DAB


On Fri, 15 Feb 2013 11:47:03 +0100, "Edward C. Zimmermann" 
<[log in to unmask]> wrote:

> 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
>>
>> On Thu, 14 Feb 2013 15:54:02 -0500, Ray Denenberg <[log in to unmask]> wrote:
>>
>> > 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
>> > additional features.
>> >
>> >
>> > Ray
>> >
>> >
>> >
>> >> -----Original Message-----
>> >
>> >> From: Discussion of the Developing Date/Time Standards
>> >> [mailto:[log in to unmask]] On Behalf Of Byrd, Donald A.
>> >> Sent: Thursday, February 07, 2013 11:41 AM
>> >> To: [log in to unmask]
>> >> 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
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington