Possible paths to many calendars

[tychonievich]

We have roughly a dozen calendars currently being considered for inclusion in 7.1 (#38). Should we

• Put them all in the appendix, like the four we have now?
• Host them in a separate document that we can add to without requiring a new minor version?
• Define a discovery format (such as a JSON format to augment the CLDR or a GEDCOM record like CALENDAR with substructures defining each calendar's format)?
• Other?

[tychonievich]

Note that the CLDR does provide information we don't, and vice versa.

CLDR has

• names of months in many languages (though some are unnamed, e.g. zh/ca-hebrew.json which calls the Hebrew months "first month" and "second month" and so on)
• names of eras (most I checked have only one era, but Gregorian has BCE and ACE)

7.0's appendix A has

• names of months in English and possibly one other language
• a short description of the calendar
• names of the past epoch
• month tags for GEDCOM encoding

neither has

• Data needed for date validating, such as days per month, leap-year rules, etc
  • note: leap-year is needed for displaying Hebrew the month name for Adar properly too
• Data needed to (approximately) convert between calendars such epoch dates
• Data about the daily epoch (days starting at midnight vs dusk vs dawn)

For some calendars, some of the above cannot be easily provides (such as leap-year rules for observational calendars or exact epoch dates for some historical calendars)

[ghost]

I feel that an adjunct to the GEDCOM spec might be best because the date rules and properties within each calendar are not fully dictated by FamilySearch

[tychonievich]

A possible way to encode the current appendix data as a GEDCOM record might be

0 CALENDAR
1 TAG GREGORIAN
1 URI https://gedcom.io/terms/v7/cal-GREGORIAN
1 NOTE The Gregorian calendar is the now-ubiquitous calendar introduced by Pope Gregory XIII in 1582 to correct the Julian calendar which was slowly drifting relative to the seasons.
1 MONTH JAN
2 NAME January
3 LANG en
1 MONTH FEB
2 NAME February
3 LANG en
1 MONTH MAR
2 NAME March
3 LANG en
1 MONTH APR
2 NAME April
3 LANG en
1 MONTH MAY
2 NAME May
3 LANG en
1 MONTH JUN
2 NAME June
3 LANG en
1 MONTH JUL
2 NAME July
3 LANG en
1 MONTH AUG
2 NAME August
3 LANG en
1 MONTH SEP
2 NAME September
3 LANG en
1 MONTH OCT
2 NAME October
3 LANG en
1 MONTH NOV
2 NAME November
3 LANG en
1 MONTH DEC
2 NAME December
3 LANG en
1 EPOCH BCE
2 NOTE year y BCE indicates a year y years before year 1. Thus, there is no year 0; year 1 BCE was followed by year 1.

We could augment it with other data, like

1 MONTH FEB
2 NAME February
3 LANG en
2 DAYS 28
2 DAYS 29
3 TYPE LEAP

and maybe even formulas like

1 LEAP_YEAR
2 AND
3 YEAR % 4 == 0
3 YEAR % 400 != 1
3 YEAR % 400 != 2
3 YEAR % 400 != 3

... though that seems like it might be going overboard

[elyoh]

In my view, having the syntax to be able to represent all valid dates in a given calendar in native form (enumerated months, enumerated epochs), is far more important than documenting all the complex rules required to check if a particular combination of day, month, and year is valid.

Whilst validation is trivial for simpler arithmetic calendars, it quickly becomes very complex for astronomical calendars, and it isn't even possible ahead of time with observational calendars (even validating historic observational dates is difficult as (accurate) table data does not always exist). Moreover, a great many dates in GEDCOM files are partial dates, and in general, it is not possible to validate these beyond simple checks on whether a given month name is valid in a specific calendar.

In terms of defining calendar rules, my go to reference guide on these matters is Calendrical Calculations: The Ultimate Edition - doi:10.1017/9781107415058. Even they are still updating, and adding to their implementations. It doesn't seem to me that the GEDCOM specifiations should seek to replicate this kind of detail. However it is a good source of truth, and more accurate than some of the data buried in CLDR. In the end, implementors are likely to rely on library functions, rather than roll their own calendar code, when validating dates in the more common calendars.