Print

Print


> On Jun 11, 2015, at 3:25 PM, Denenberg, Ray <[log in to unmask]> wrote:
>  
> ‘?’ (question mark) currently means “uncertain”, ‘~’ (tilde) means “approximate, and ‘?~’ means “uncertain as well as approximate”.  The suggestion is to replace the latter with a single character and the suggested character is ‘%’ (percent).

This seems to be trading usability for terseness. Considering how rarely these will be used together in practice, I think it is overkill to try to optimize this down to one character. It will simply create more confusion.


> ‘u’ means unspecified, and the suggestion is to change that to ‘!’ (exclamation).

If punctuation is preferred, I would recommend "_", so there's at least some language-independent semantic value to the placeholder character. "!" looks too much like "1", and its only value here seems to be that it is otherwise currently not in use.

We could also use "?" for an unknown/unspecified digit (which makes perfect sense) and use "^" for the "uncertain" modifier. Using "^" has the advantage that *both* of our modifier characters are rendered above the x-height, which helps visually distinguish them from the value characters.

I know we're currently using the "^" for the seasonal qualifier. If we decide to retain this feature (I think we should remove it), "!" may be a better choice for that delimiter.

(Oddly enough, there are two characters that specifically mean "uncertain" (U+2BD1 and U+3A8E), but I suppose we need to stick with ASCII. :))


> ‘y’ is used at the beginning of the date string to signify that the date is a year exceeding four digits. The suggestion is to change this to ‘Y’ (upper case).

I agree with Nathan that a "+" and "-" makes more sense for this. This is more consistent with ISO 8601. The "+" or "-" should be required for situations where there are more than four digits, required for exponential dates, and mildly recommended for dates before January 1, 1583.

As an aside, EDTF currently follows ISO 8601 in requiring at least 4 year digits, but we might consider loosening this restriction. The only reason ISO 8601 requires this is because they have a non-expanded form (no "-" delimiters), so shorter year values could result in ambiguous dates. We don't have that issue, so we should consider allowing dates like "707-07-18" or "-44-03-15".


> ‘unknown’ and ‘open’ : the suggestion is to replace these with single characters, and the suggested characters are ‘*’ and ‘&’  (asterisk and ampersand).

Using "*" for "open" sounds like a good idea to me. "*" is used as a wildcard in many pattern languages.

Simply not having anything on the "open" end of the "/" also makes perfect sense to me. That's more consistent with our notation for open-ended sets (before/after).

Assigning "&" for "unknown" appears to be another case where someone is simply searching their keyboard for unused punctuation characters. This does not serve end users well.

For an unknown date, we could simply use "uuuu-uu-uu" or some variation of that. This has the added advantage of allowing *some* knowledge to be conveyed. For example, if I know someone was born in 1850, I can reasonably assign a death date as "1uuu-uu-uu". For situations where my start date has a lower precision, I can also match the precision for the unknown end date (e.g., "1850-uu/1uuu-uu"). (See above re: using "_" instead of "u", the same principle applies.)


> The suggestion is to rename these four,  and expand the list:
> ·         21 = Spring - Northern Hemisphere 
> ·         22 = Summer - Northern Hemisphere
> ·         23 = Autumn/Fall - Northern Hemisphere
> ·         24 = Winter - Northern Hemisphere
> ·         25 = Spring - Southern Hemisphere
> ·         26 = Summer - Southern Hemisphere
> ·         27 = Autumn/Fall - Southern Hemisphere
> ·         28 = Winter - Southern Hemisphere

Making the value of a date dependent on geography is problematic for any sort of conversion, sorting, comparison, etc. We already have enough of this going on with time zones, we don't need it for seasons as well.

I would suggest we simply define these as Astronomical Seasons 1, 2, 3, and 4 so each logical date range between the various solstices and equinoxes has only one canonical form. So, a date of 2015-21 could be rendered as "Autumn 2015" for a user in the Southern Hemisphere and as "Spring 2015" for the North, just as localization routines currently handle the names of the months differently based on locale.

(Of course, the actual date and time of the equinoxes and solstices can float a bit from year to year and place to place, I'm talking about the average solstice and equinox dates -- March 20, June 21, September 22, and December 22 IIRC.)


> ·         31-34 for Q1 - Q4 ( 4 periods of 3 months each)
> ·         41-43 for Quadrimester (3 periods of 4 months each)
> ·         51-52 for Semestral (2 periods of 6 months each)

These have no universal definitions, and as such have no real place in a international standard, IMHO.

If we feel there is a real need for users to be able to use EDTF to store portions of a year (calendar, fiscal, academic, or otherwise) that have no universal meaning, I recommend we simply state that values 30-99 are valid for private use but have no specific definition.

There may be enough universal, culture-neutral interest in defining four quarters for January-March, April-June, etc. If that is the case, maybe those can be assigned values 25-28, but all other meanings of "quarters" (fiscal, etc.) that don't align with those date ranges would need to use the private values.

--Richard