Edward's message hints at the endless complexity of time descriptions 
in the real world! I'm very interested myself in everything Edward 
wants. But to avoid getting bogged down in details ourselves _and_ to 
save people who want to implement EDTF and don't need fancy features, 
let's not forget EDTF's division into levels, which I think is a very 
good idea.

* For EDTF Level 0, I propose we add _only_ the ISO 8601 syntax for 
fractional seconds used by xsd:dateTime, exactly as suggested by 
Saasha. As for whether the number of decimal digits after the dot in 
EDTF-born data should be potentially unlimited, I'm pretty sure that 
both 8601 and XSD allow that, but 8601 suggests implementations specify 
a maximum number of digits they handle; I propose EDTF do the same 
thing, specifically allowing that number to be zero.

So an implementation might allow any of these descriptions of a certain time:


...assuming it specified enough digits. NO other way to describe that 
time with better than 1 sec. precision would be allowed. If the 
implementation supports zero digits after the dot, none of those 
descriptions would be legal.

* For EDTF Level 1 or 2, I propose we add fractional minutes and 
fractional hours, interpreting them exactly as suggested by Saasha.

* For EDTF Level 2, I propose we _consider_ support for the kind of 
thing Edward mentions -- essentially, specifying completely arbitrary 
non-decimal precision (is that a fair statement, Edward?). But I 
suspect it'd make more sense to add it the list of future features in 
Annex A, with a high probability of it ending up in Level 3.


On Sat, 16 Feb 2013 20:56:16 +0100, "Edward C. Zimmermann" 
<[log in to unmask]> wrote:

> On Fri, 15 Feb 2013 16:52:48 +0100, [UTF-8?]SaaÅ¡ha Metsärantala wrote
>> Hello!
>> > "For time, is hour:minute:second sufficient, or do we need to support
> fraction of a second?"
>> In the library / museum / archive world, expressing something similar to
>> "during the 1870'ies approximately" is often a more useful feature than a
> The two are hardly exclusive. I think I've been quite strong in voicing my
> position on precision/readability and data reliability/repeatability.
> Decade, century or .. "precision" is no different than minute, second,
> millisecond, nanosecond,... "precision".
>> precision at the millisecond's level. This is one of the reasons why there
> Millisecond is a decimal model of precision. There are others.
> The Jewish time model is an example of a non-decimal time model that is
> currently widely used.
> Jews all over the world use a time with a precision of 1/72 a time degree
> (Halokim) or  3 1/3 seconds (1/18 minute). The precision of the date/time for
> events such as new month (defined by moon) is 3 1/3 seconds.
> Just as we have ..., decade, year, month, day, hour, minute, second,
> millisecond,... models in the ISO world we have also ...,day, hour, minute,
> halokim, regaim (76 regaim = 1 halokim) in the Jewish ... (to make
> things even
> more complicated the time for lunar festivals is the time of the event in
> Jerusalem)
> Since hour, minute, second are based on degrees and are not decimal (60
> seconds= 1 minute, 60 min= 1 hour, 24 hours = 1 day) to demand that
> the minute
> be divided by tens is a break in design---- the Napoleonic system went the
> other way to define 1 year = 10 months, 1 day = 10 hours, 1 hours = 10 ...)
>> was a need for EDTF and the reason why we focused on approximations (and
>> other features) more than fractions of seconds.
>> If you consider it is useful (and it may probably be useful in some
>> cases), it is OK for me to add this feature in EDTF. It is quite easy to
>> modify the BNF for that and there should probably not be major problems to
>> implement a parsing taking fractions of seconds into account. There are
>> several more crucial (but also more difficult to describe and implement)
>> features to be added to EDTF and I consider that fractional seconds is not
>> a priority, but I consider it is OK to add this feature at level zero,
>> remembering that it is part of xsd:dateTime
>> to which I suggest to
>> stick. Let's keep in mind though, that according to
>> (page 16) ISO_8601 reads:
>> > "the decimal fraction shall be [...] the comma (,) or full stop (.). Of
> these, the comma is the preferred sign."
>> and
>> > "a decimal fraction of hour, minute or second may be included."
>> whereas xsd:dateTime only allows dots (full stops) as separators and only
>> allows fractional seconds (not fractional hours nor fractional minutes).
>> This should not be a problem though, because EDTF level zero is defined as
>> a profile of ISO_8601.
>> Regards!
>> [UTF-8?]Saašha,
> --
> Edward C. Zimmermann, NONMONOTONIC LAB/BSn
> Umsatz-St-ID: DE130492967

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