This clears everything up. Thanks. --DAB
On Dec 4, 2015, at 4:34 PM, "Denenberg, Ray" <[log in to unmask]>
> > Donald Byrd
> >Why allow, e.g., "19" to represent the
> > 1900s (or possibly the 20th century? I forget), with attendant confusion
> > about how to represent the year 19 C.E., when we already allow "19XX" (or
> > some such; I'm not sure what current thinking is about the last two chars.)?
> '19' will continue to represent the 1900s, it is entrenched in 8601 and we have no power to change that (even if we wanted to, which personally I don't.)
> "year 19" is '0019'. I don't think there is any confusion about that.
> As to ‘19XX’ vs. ‘19’: Actually, in the EDTF draft spec there are 19uu and 19xx, which mean subtly different things. The ISO group has changed ‘u’ to ‘X’ (that is, they changed it to ‘x’ and also changed it to upper case). The disposition of the previous use of ‘x’ is unclear at this time.
> Anyway, ‘19’ and ‘19XX’ do not mean the same thing.
> ‘19’ means the 1900s, the 100 year period (or it could pertain to an event that occurred during the 1900s, it depends on the application, i.e. the definition of the data element taking on that value).
> ‘19XX’ means a specific year in the 1900s, and that that year is not yet specified (it may be specified – filled in – some time in the future – no guarantee). For a publishing application, for example, a book is published (usually) some year, not “during some 100 year period”. If you don’t find the distinction useful, or have no use for the XX notation, don’t use it.
> > Along the same lines, in 2004, 8601's Basic format might have been a good
> > idea; now that disk space is incredibly cheap and bandwidth is orders of
> > magnitude cheaper than in 2004, I think it'd make sense to deprecate and
> > eventually drop Basic format and require Extended format. We're likely to
> > want to represent more and more complex temporal information, and
> > maintaining compatibility with very short formats is likely to be a bigger and
> > bigger albatross around our necks as time goes on.
> Well we don’t have any say about deprecating basic format for 8601 part 1. And such a change would never be approved because it would be incompatible with existing applications. However, all of the EDTF level 1 and 2 features (i.e. extensions to 8601 part 1) to be incorporated into 8601 part 2 will require extended format. And EDTF level 0, which is really a profile of 8601 part 1, already requires extended format, but it cannot impose that requirement on 8601 part 1 in general. However, part of this work will be to develop a profile, which will be based on EDTF and so of course will require extended format. I’ll have more to say about this profile as it develops.
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington