> Interesting ideas here, however, well, I'm all in favour of explicitness and clarity.

>

> So how about having a core spec which dispenses with precision in favour of explicit ranges, and clarifies the mapping between existing implicit precision expressions and their explicit ranges?

>

> 1985 = [1985-01-01 ... 1985-12-31] or something like that?

A date is not a range (interval). You are free to handle precision in your implementation as if it was a range but they are really quite different and can result in different results.

We are dealing with precision all the time. 1985-01-01T12:01 is second precision. ISO 8601 goes down to milliseconds in precision. Do you really want to start to define every date as a interval? Here 1985-01-01 as 1985-01-01T00:00:000/1985-01-01T24:59:999?

1985 = [1985-01-01T00:00:000 ... 1985-12-31T24:59:999] using your notation.

What's the range interval 1985-1986 ? 1985-01-01T00:00:000/1986-12-31T24:59:999 ?

But wait a minute.. If I have millisecond precision I must have, at least, time zone precision.. So where is the interval 1985 defined? By UTC? Or if a book was published in 1985 in Berlin shall we have call to define the year as a range using a span of time in Middle European time?

And how do we know to distinguish between dates with seconds specified and ... I'm thinking about search and retrieval applications--- what I keen on.

Its, I think, like walking into a shop and asking for 100g of cheese and demanding that it be measured out in 1/10 of a mg. On the other hand.. there are loads of applications where 1/10 of mg is of significance--- that's why there are analytical balances. While there are applications where fractional microns matter do we want to measure out everything in fractional microns.. such as the length of a farmer's field?

In science and engineering we talk explicitly about precision all the time. Why not here?

> We don't need any completely new expression method (particularly not one that is less familiar to people than the perhaps already unfamiliar formats introduced anyway...)

>

> Simon

>

> On 28 November 2010 15:31, Edward C. Zimmermann <[log in to unmask]> wrote:

>

> Just playing around with things....

>

> Thinking more.. do we perhaps want to toss the whole u model and instead introduce a direct system of

> specifying precision.

>

> We already have implicit precisions:

> 1985 <- implicit year precision

> 1985-12 <- implicit month precision

> 1985-12-12 <- implicit day precision

> 1985-12-12T12 <- implicit hour precision

> 1985-12-12T12:12 <- impliciut min. precision

> 1985-W3 <- implicit week precision

>

> How would we express "20th century"? That's century precision.

> [In u format: NNuu where N is 0-9, e.g. 19uu ]

>

> Just for the sake of discussion lets call this Pn.

>

> P1 would mean 1-unit precision. A year

> P1(1955) would be 1955--- 1955 as date is implicitly in year precision.

>

> P100(1985) -> 100 year precision of 1985 -> 20 the century

>

> P100(1985) = P100(1910) etc.

>

> P10 (1955) -> 10 year precision of 1955 -> The 1950s.

> [In u format: 195u]

>

> We can apply this to months and even days

>

> 1955-12- P10(1) would be 1-9 in Dec. 1955 with 10-day precision.

> [What in u format as 1955-12-0u]

>

> This format tosses out things like 1uu9 (see previous mail) but now includes some more interesting cases where we have

> Pn where n is not limited (as in the u case) to 1,10,100 etc. but can be any natural number.

>

> Recall that we also have week dates... YYYY-Www-D

>

> 1955-WP4(23)-2

>

> This is a precision of 4 weeks--- contrast to month-- but also a specification that its Mondays.

>

> 1955-WP54(1)-2 would say the event took place on Monday in 1955.

>

> 1955-WP26(1)-2 would say the event took place on Monday in the first half of 1955.

>

> Here there is no talk anymore about "unknown" but directly precision.

>

>On Fri, 26 Nov 2010 13:02:09 +0000, Simon Grant wrote

>

> > "Hammer this into the ground" sounds unwarrantedly rough, but, well, let's try to finish the discussion positively...

> >

> > On 26 November 2010 12:28, Edward C. Zimmermann <[log in to unmask]> wrote:

> >Pragmatically:

> >

> > [...]

> >195u means the event took place in the 1950s (its unit of precision is 10 years)

> >

> > = [1950...1959]

> >19uu means that the event took place in the 20th century (its unit of precision is 100 years)

> >

> > = [1900...1999]

> >1uuu means that the event took place in the second milennia (its unit of precision is 1000 years)

> >

> > = [1000...1999]

> >uuuu means that we don't know when the event took place[...]

> >

> >But the 'u' delivers more:

> >

> > uu59 means that we know the event took place in the year 59 but don't know the century

> >

> > A very unlikely case, extending as it does into the future.

> > = [1059, 1159, 1259, ..., 9959] (sorry, needed to shorten that one :-)]

> >1u59 means that we know the event took place in the year 59 in the second milennia but don't know which century.

> >

> > Slightly less unlikely, though the only reason I can think of is that we have found a book with a ripped-off page. Do we really want to be dealing with these edge cases?

> >

> > = [1059, 1159, 1259, 1359, 1459, 1559, 1659, 1759, 1859, 1959]

> >

> > [...]

> >

> > > However, in both cases this states a claim or belief that the actual value

> > is one of the set running all the way from 1980 to 1989. I don't see any

> > *pragmatic*, *operational* reason for making a distinction. Furthermore, I

> > believe that if such a distinction were made, in practice people would argue

> > over or confuse the two, leading to inconsistency of semantics. The

> > consequence would be that in practice, both forms would have to be treated

> > equally in any case.

> > >

> >

> > The extended date system has not provision at this time for |.

> >

> > In our systems (matching and searching dates) we would all probably handle

> > them as the same but the sentence

> >

> > But.. just to hammer this into the ground...

> >

> > 195u is expressing something known (1950s)

> > 195| is expressing more: Not only is it known that the event took place in the

> > 1950s but we claim to be able (at some future time) to increase the precision.

> >

> >

> > This is an important distinction. I would strongly advise *against* trying to include in a standard like EDTF any implication of a claim that precision may increase in the future. It seems much too vague a concept to be representing in a standardized way.

> >

> >

> > 195| is essentially claiming a year precision but expressing that the year is

> > not yet collected. Its a kind of "volatile" flag announcing that the precision

> > might increase at some future time.

> >

> >

> > Would people really agree on exactly what such a "volatile" flag might mean? I suggest going through the process of finding out, from real people, what they agree on here. My guess is that what they will actually consistently agree on is that the value is not known now :-) Glad this is not in the EDTF proposal: I would oppose it in carefully and forcefully argued terms.

> >

> > Really, you can't just include something in a public standard because it seems like a good idea to a few people. To be useful, it has to express a concept that there is genuine common agreement about. Otherwise, write a private or proprietary standard to be used among the group of believers. No one will stop you doing that. :-)

> >

> > Simon

> > --

> > Simon Grant

> > +44 7710031657

> > http://www.simongrant.org/home.html

>

> --

>

> Edward C. Zimmermann, NONMONOTONIC LAB

> Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts

> Office Leo (R&D):

> Leopoldstrasse 53-55, D-80802 Munich,

> Federal Republic of Germany

> http://www.nonmonotonic.net

> Umsatz-St-ID: DE130492967

>

>

> --

> Simon Grant

> +44 7710031657

> http://www.simongrant.org/home.html

--

Edward C. Zimmermann, NONMONOTONIC LAB

Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts

Office Leo (R&D):

Leopoldstrasse 53-55, D-80802 Munich,

Federal Republic of Germany

http://www.nonmonotonic.net

Umsatz-St-ID: DE130492967