AGE payload issues

[dthaler]

Are the following AGE payloads legal?

AGE 8w 30d
AGE 1y 400d
AGE 1y 30m
AGE 1m 40d

Section 2.4 says about dates:

The allowable days, months, years, and epochs are determined by the calendar. All known calendars restrict day to be between 1 and a month-specific maximum. The largest known maximum is 36, and most months in most calendars have a lower maximum.

But nothing says that AGE payloads have any similar restrictions, implying that all four examples are permitted, and are not even discouraged.

A closely related problem is that say someone has events in two different calendars, say both FRENCH_R and GREGORIAN, then their age in terms of months and extra days can be different in each calendar. The AGE tag has no calendar permitted in the payload. One might infer it from the DATE of the event, if there is one, but AGE is permitted in cases with no DATE. I would expect most applications to store it in GEDCOM exactly as it was given in the original record, but that is not interoperable if other programs use it to calculate the date but interpret it in the wrong calendar.

Some possible actions:

1. We could possibly add a Note saying the uses up top are not recommended (I think we can't disallow them without a breaking change) and applications should use the simplest form. Rationale to NOT add such a note might be to allow recording ages as they literally appear in a record. But a Note that applications must be prepared to see them might be helpful.
2. Recommend that when AGE is used, there should be a DATE with it, where a CAL payload can be used to disambiguate which calendar. Otherwise, some programs might calculate incorrect dates based on using a calendar other than the correct one for the event.

[dthaler]

Discussion in GEDCOM Steering Committee1/18/2024:

• We have no way to store the calendar of an age
• A DATE and AGE might both be in an original record and so don't necessarily match
• Could be discussed in a FAQ
• Having a Note in the spec is ok if wording is right, to promote more interoperability
• Lines at top are ok to be in test files
• May be ok to have a note in the spec saying it's ok to record as is