RE: Re-writing Genealogy::Gedcom::Date

[email protected] ("John Washburn") Fri, 6 Nov 2015 20:08:55 -0600
Newsgroups perl.gedcom
Organization John Washburn
Message-ID <000001d11901$42a9a1d0$c7fce570$@org>
O yeah.  Dates and time are a can a worms.  Moreover the worms under study
wiggle all the more fiercely the more closely you focus on them (i.e.
examine the details of dates and calendar representations).  The key
revelation for me 15 years ago was that date and calendar are not the same.

Sorry I mis-understood the scope of the date package.  Removing date math
does simplify things greatly and eliminates the need to adopt a core
calendar representation for the internal description of dates.

I should have been more clear in my email that parsing or printing a string
representation of a date requires a both a calendar and a culture.  For
example it is possible to have date represented by the Gregorian calendar in
French, German, or English just as it would be possible to use the Hijri
calendar in English or Tamil to represent or parse a date.  The names of the
months have to be translated from Arabic to English or Tamil. 


-----Original Message-----
From: Ron Savage [mailto:[email protected]] 
Sent: Friday, November 06, 2015 5:22 PM
To: [email protected]; [email protected]
Subject: Re: Re-writing Genealogy::Gedcom::Date

Hi John

Thanx for your informative email.

Luckily my code is not intended to do any calculations. It simply accepts,
parses and returns date strings - which must be provided in a given format.

I did read various parts from your references and understand they are
complex for good reason. The whole topic is a marvellous example of a can of
worms.

Regarding writing new code:

As for ISO 8601, I could buy a copy of the doc for $AUD235, or start with a
similar standard, RFC 3339 for free.

As for the BNF on p 12 of RFC 3339, it resembles the BNF for "RFC4514: 
Lightweight Directory Access Protocol (LDAP): String Representation of
Distinguished Names." [1] for which I have already written a Marpa::R2-based
parser [2]. So, definitely doable, but fortuitously not needed at this point
in time.

[1] https://www.ietf.org/rfc/rfc4514.txt

[2] https://metacpan.org/pod/X500::DN::Marpa
--
Ron Savage - savage.net.au