FamilySearch/GEDCOM

Date, dateRestrict, epoch: confusing constraints

Closed this issue · 4 comments

geostag commented

dateRestrict contains tags, which must not be recognized as month, calendar or epoch (mentioned in additional contraints). dateRestrict however contains "BCE" which is a valid tag in epoch. This seems confusing.

tychonievich commented

Agreed; that is a contradiction in the spec.

An epoch can be unambiguously detected as such because it is the only token that can appear after the last integer in the date. I thus think we can remove this ambiguity in three ways:

  1. Remove "epoch" from "No calendar names, months, or epochs match dateRestrict." That means a calendar could define ABT as an epoch.
  2. Remove "BCE" from the definition of dateRestrict. That means a calendar could define BCE as a month.
  3. Both of the above.

My gut is option 2 because it keeps all three calendar-defined tag types the same, but I'm OK with any of the three. Opinions?

geostag commented

From my point of view, option 2 seems a good choice.

elyoh commented

Option 3 would seem to allow a future calendar to define a month TO, an epoch TO, and a calendar TO and we begin to allow insidious examples such as FROM TO 1 TO 1987 TO TO TO 5 TO 1987 TO. This is does not seem desirable at all. It certainly increases complexity of date parsing and reduces human readability.

Ensuring that month, epoch, and calendar names do not overlap with key words FROM, TO, AFT, BEF, BET, AND, ABT, CAL, EST means one can easily extract the date part(s) in dateApprox, dateRange, or datePeriod without any further knowledge about the structure of date, or any calendars that have or will be defined. For me this would preclude the use of option 1.

Option 2 does address the contradiction with minimal impact (I think a parser which supported extension calendars would already have to rely on detecting epochs in the way described by @tychonievich). Is it such a good idea to allow month names to be the same as epoch names? Are there genuine use cases for month and epoch to have overlap?

dthaler commented

Option 3 would seem to allow a future calendar to define a month TO, an epoch TO, and a calendar TO

That isn't my understanding. Option 3 would be:

dateRestrict = %s"FROM" / %s"TO" / %s"BET" / %s"AND" / %s"BEF" / %s"AFT" / %s"ABT" / %s"CAL" / %s"EST"
...
No calendar names or months match dateRestrict.

Thus no calendar names or months can be TO.

Is it such a good idea to allow month names to be the same as epoch names?

In my view a parser should be able to deal with the difference (one being before the year and the other being after the year, and the year is mandatory) so it shouldn't matter.

I am fine with any of the three options.