Ron:
You may have to consider support for Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> . Hear me out I have worked in logistics software for some many years and date calculations are the bedevilment of anything that touches the notion of date/time. For example, the implementations of native DateTime objects in the major databases (Oracle, Sybase, Ingress, SQL Server, Informix, DB2, etc.) are all subtle difference; e.g. date time model for these is the number of seconds since second ZERO but the resolution on the second (3 or 6 places) varies and the exact date time of the second zero (in the proleptic Gregorian Calendar <https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar> ) varies. Also is NULL (no date information) supported or not varies from DB to DB. Similarly the underlying implementation of date time for Perl, Java, C#, etc has the same Modeling and NULL-bility variations. It took me some time to realized that I was confusing date with calendar. Date is a particular point in time. Calendar is how to describe that point in time. We found the most uniform way to deal with date and times was pick a core calendar and to store the string representation on the database. We chose to store a string on the data base in ISO_8601 <https://en.wikipedia.org/wiki/ISO_8601> format of the proleptic Gregorian Calendar <https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar> with UTC as the date portion down to the second. This sufficed for our dates; lots, holds, receipts, shipment, orders, etc. and it supported NULLs (e.g. the ship date is NULL because the order has not shipped yet) Dates math was then 1) convert from proleptic Gregorian date <https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar> to Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> , 2) Do your date math (e.g. subtract two dates or add 17 days) 3) Covert from Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> to proleptic Gregorian date <https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar> 4) Store ISO ISO_8601 <https://en.wikipedia.org/wiki/ISO_8601> representation of the proleptic Gregorian date <https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar> Perhaps GEDCOM dates needs to have at its heart dates in the form of Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> (with suitable qualifiers for (abt, circa, before, etc) and suitable qualifiers for resolution (e.g. nearest decade, nearest year, nearest month). Converting into, out of, and between calendars becomes simplified, because the astronomical community has wrestled with this issue for more than 2 centuries and developed algorithms to convert all of the know calendars of man into Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> and back to a local calendar. I propose the internal structure of a Gedcom date be an object with Astronomical Julian Days <https://en.wikipedia.org/wiki/Julian_day> and two kinds of qualifiers: Certainty (exact, abt, before, after, unknown, etc.) and Resolution (NULL, Nearest century, decade, year, month, day, etc.). Parsing a string then is to convert from a string representation from a local calendar (Gregorian, Julian, French republican, Hebrew, Islamic, Mayan, etc.) to the internal Julian day format. Date math (e.g. life span) is done with internal representation of genealogically qualified Juliann days. Example Died before ZZZZ minus born after YYYY is and either an age of about AAAA or and age of more than BBBB Printing a date string is to convert from the internal Julian day format to a string representation using the specified local calendar (Gregorian, Julian, French republican, Hebrew, Islamic, Mayan, etc.). There is no notion of parsing or printing a date without also specifying the local calendar by which the string is parse or printed. Also NULL dates (e.g. empty string) are supported so you can signify the absence of date information; e.g. have a birth date and a NULL death date indicates (possibly) a living person This presents more foundational work up front for GEDCOM Dates, but it permit the expansion to more local calendars over time and provides for uniform date math regardless of the calendar used to describe the date. Date, date math, creating a string representation, parsing a string representation, and supported local calendars are decoupled from each other. I hope this helps more than confuses. I have wrestled with dates and date math off and on since 1996 and the above flows from the mistakes and successes I have had. -----Original Message----- From: Ron Savage [mailto:r...@savage.net.au] Sent: Wednesday, November 04, 2015 3:32 PM To: perl-gedcom@perl.org Subject: Re: Re-writing Genealogy::Gedcom::Date Hi I should add: Thanx to all who have been replying to this thread. -- Ron Savage - savage.net.au
