RE: Re-writing Genealogy::Gedcom::Date
[email protected] ("John Washburn") Fri, 6 Nov 2015 08:06:02 -0600
| Newsgroups | perl.gedcom |
|---|---|
| Organization | John Washburn |
| Message-ID | <000e01d1189c$491d8050$db5880f0$@org> |
------=_NextPart_000_000F_01D11869.FE831050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:[email protected]] Sent: Wednesday, November 04, 2015 3:32 PM To: [email protected] 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 ------=_NextPart_000_000F_01D11869.FE831050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:131870722; mso-list-type:hybrid; mso-list-template-ids:2031146952 67698705 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue = vlink=3Dpurple><div class=3DWordSection1><p = class=3DMsoPlainText>Ron:<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>You = may have to consider support for <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a>. Hear me out<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>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 <a = href=3D"https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">prole= ptic Gregorian Calendar</a>) 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.<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>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. <o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>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 <a = href=3D"https://en.wikipedia.org/wiki/ISO_8601">ISO_8601</a> format of = the <a = href=3D"https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">prole= ptic Gregorian Calendar</a> 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)<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>Dates = math was then <o:p></o:p></p><p class=3DMsoPlainText = style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1)<span = style=3D'font:7.0pt "Times New Roman"'> = </span></span><![endif]>convert from <a = href=3D"https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">prole= ptic Gregorian date</a> to <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a>, <o:p></o:p></p><p class=3DMsoPlainText = style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>2)<span = style=3D'font:7.0pt "Times New Roman"'> </span></span><![endif]>Do = your date math (e.g. subtract two dates or add 17 days)<o:p></o:p></p><p = class=3DMsoPlainText = style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>3)<span = style=3D'font:7.0pt "Times New Roman"'> = </span></span><![endif]>Covert from <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a> to <a = href=3D"https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">prole= ptic Gregorian date</a><o:p></o:p></p><p class=3DMsoPlainText = style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>4)<span = style=3D'font:7.0pt "Times New Roman"'> = </span></span><![endif]>Store ISO <a = href=3D"https://en.wikipedia.org/wiki/ISO_8601">ISO_8601</a> = representation of the <a = href=3D"https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">prole= ptic Gregorian date</a><o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>Perhaps GEDCOM dates needs to have at its heart = dates in the form of <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a> (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 <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a> and back to a local calendar.<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>I = propose the internal structure of a Gedcom date be an object with <a = href=3D"https://en.wikipedia.org/wiki/Julian_day">Astronomical Julian = Days</a> and two kinds of qualifiers: Certainty (exact, abt, before, = after, unknown, etc.) and Resolution (NULL, Nearest century, decade, = year, month, day, etc.).<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>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.<o:p></o:p></p><p class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>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<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>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.).<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>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<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>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.<o:p></o:p></p><p class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>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.<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>-----Original Message-----<br>From: Ron Savage = [mailto:[email protected]] <br>Sent: Wednesday, November 04, 2015 3:32 = PM<br>To: [email protected]<br>Subject: Re: Re-writing = Genealogy::Gedcom::Date<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>Hi<o:p></o:p></p><p = class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>I = should add: Thanx to all who have been replying to this = thread.<o:p></o:p></p><p class=3DMsoPlainText><o:p> </o:p></p><p = class=3DMsoPlainText>-- <o:p></o:p></p><p class=3DMsoPlainText>Ron = Savage - savage.net.au<o:p></o:p></p></div></body></html> ------=_NextPart_000_000F_01D11869.FE831050--