In part 2, section 4 is EDTF levels 1 and 2, although EDTF is not mentioned in that section.  (Section 5 “Repeat rules for recurring time intervals” is an extension unrelated to EDTF.)  Annexes B and C are about profiles.  B introduces the concept of profiles, and C is the EDTF profile. It introduced level 0, which is not mentioned in section 4 because none of the level 0 features is an extension.

Thanks Ray!

My initial thoughts:

— The phrase “reduced accuracy” should be “reduced precision.” Saying that the current date is 2016 is not less accurate than saying the current date is 2016-02-23, it’s simply less precise. (And, tomorrow, 2016 will actually be a more accurate representation of the current date than 2016-02-23 will be, because of said lower precision.)
— Concerns with “%”:
1. “~?” would be far more intuitive for both humans and parsers. Using these in combination will be a rare use case, so giving that combination its own special character (presumably to “save” space?) adds needless complexity and wastes one of the few remaining ASCII characters that may be put to far more important uses in the future. [Agreeing with Nathan here]
2. Dates taking advantage of EDTF features will be stored in string form in most databases, and many databases use “%” as a wildcard in their SQL syntax. This then makes it more difficult for users to distinguish whether they are looking for literal “%” or using it for pattern-matching. This is not a show-stopper, but is a concern for real-world applications.

— I’m glad the left/right syntax passed, it’s far better IMHO than the parenthesis sets in the draft.
— Under guidelines:
1. “Fewer,” not “less.”
2. I would argue that “2015?” is preferable to “?2015”, because the former is more likely to align and sort among other dates more reasonably in string form, and thus will be more user-friendly.

— I would have preferred “x” since the lowercase form is easier to pick out visually, but “X” is acceptable.
— Renewed objection to misuse of the term “accuracy.”
— An example should be included to show how the “X” works for years before 1000, e.g., “003X: an unspecified year sometime during the A.D. 30’s”.

— I feel strongly that this should also use the “..” to allow representation of an unspecified value that is “between” two dates (inclusive), such as “2015-01-22..2015-04.20”. This is not the same thing as a closed interval of “2015-01-22/2015-04-20”. Adding this feature will also make this syntax far more consistent with how it is used inside of [] and {}.

— I agree with Nathan, use of “*” should indicate an explicit open (“everything”) side, not an unknown, and lack of the “*” is a better indication of something that is unknown. But I’d also like to suggest that we could just use “..“ to indicate the open side rather than wasting “*” on it. For example:
1984/.. ==> beginning 1984, no end date
../2015 ==> no start date, ending 2015
../.. ==> eternity

Using “..” rather than “*” makes 4.5.2 a more natural and elegant expansion of 4.5.1, and also avoids the problem that “*” is used quite frequently as well in software  as a wildcard character and should thus be avoided when possible.

— The last example is missing the word “ending.”
— As with 4.4 above, it should also be possible to put a date before and after the “..” to indicate “between." Example:
2015-01-02/2017-04-01..2018/12/31 ==> The interval on or after 2015-01-02 and ending sometime between (inclusive) 2017-04-01 to 2018-12-31.

— I agree with Gerry, the “Y” prefix should be required for any years exceeding 4 digits and optional (not disallowed) for any years with 4 digits. Furthermore, when “Y" is used, regardless of the number of year digits, there should be no need for “mutual consent” to allow either negative years or years before 1583. Use of the “Y” indicates explicit use of this extension, which should then imply that we can represent any year we want without further handshaking.

— The first set of examples uses a “Y” prefix, the exponent examples use “y”. Is the case significant in either?

— As with “X”, I think using a lowercase “s” would make it easier to visually parse these and to not confuse them with 5’s.
— It should be made clear that “S” can only be used in conjunction with a year part, but that one can still specify a month and date. At least I’m assuming this would be valid. Also, it seems reasonable that “S” should not be used in conjunction with “~” or “X”. Example:
1950S2-12-25 ==> Some Christmas Day between 1900 and 1999, estimated to be 1950.

— Should we suggest reserved numbers for “fiscal quarter”? Obviously the exact meaning of the period would be of private interpretation, but disambiguating it from a traditional calendar quarter might be useful.
— There should be a reserved area set aside expressly for private-use year divisions (say, 90-99).

— I still dislike 8601’s overly terse century form and don’t like us suggesting that the decade form follow it, but I’ll wave the white flag on this. :)