Revision history for Perl extension Genealogy::Gedcom::Date.

1.08  Wed Jun 26 11:00:00 2013
	- Rename CHANGES to Changes as per CPAN::Changes::SPEC.
	- Update pre-preqs' version #s, especially for DateTime and DateTime::Infinite, to see if that fixes
		mysterious CPAN Tester failures with t/date.t's use of '15 Jul 1954'.

1.07  Fri Mar 23 16:51:00 2012
	- Patch code and tests for Solaris, where Data::Infinite::(Past, Future) return '-Infinity' and 'Infinity'.
	- Turn off debug in tests.

1.06  Thu Mar 22 09:18:00 2012
	- No code changes. No need to upgrade.
	- The only patch is that debug is enabled in all test scripts. The point is to report as much information
		as possible when CPAN Testers using Solaris run tests. Unfortunately, no CPAN Tester in this situation
		has responded to my direct emails, so I'm using this mechanism to get the info I need. This is all part
		of the mess MS Windows and Solaris make when failing to handle Data::Infinite::(Past, Future).
		The next version will of course just have debug turned off again, along with a Solaris fix.
		After that, I never want to hear about this problem again.

1.05  Sat Mar 17 17:29:00 2012
	- CPAN testing showed more cases where the patches in V 1.02 had to be applied.

1.04  Fri Mae 16 14:37:00 2012
	- Aggghhhh. Fix tests to match fix in V 1.03. Tests worked under Debian of course.

1.03  Wed Mar 14 17:16:00 2012
	- Add complexity to the fix for problems to Data::Infinite::(Past, Future) for OSes:
		o Win32::GetOSName = Win7
		o Win32::GetOSName = WinXP/.Net

1.02  Tue Mar 13 08:57:00 2012
	- Bump pre-reqs for DateTime and DateTime::Inifinite from V 0.70 to V 0.72, since these are the latest (today).
	- Fix sub _init_flags() for systems where DateTime::Infinite::Past is returned as '-1.#INF' instead of '-inf'.
		For testing, this only affects the 2 tests in t/escape.t where we expect '-inf' as the output for one_date.
		For end users of course, the change in sub _init_flags() is what matters.
	- Update the docs to explain that '-inf' is returned even when the system returns '-1.#INF'.

1.01  Wed Feb 29 09:35:00 2012
	  - No code changes.
	  - Update pre-req Hash::FieldHash from V 0.10 to V 0.12, in presumably hopeless attempt to rectify a CPAN Tester report about failure under MS Windows.
	  	See: http://www.cpantesters.org/cpan/report/9c177958-6ca0-1014-a634-88fc0063837e. The code tests perfectly on my Debian stable system.

1.00  Thu Sep 20 13:47:00 2011
	  - Initial release. This is an updated version of DateTime::Format::Gedcom V 1.00.
	  	This latter module is deprecated. Details in the FAQ.
	  - Changes since DateTime::Format::Gedcom:
	  	o The hashref returned by the parse_*() methods includes 4 new keys:
		  one_default_day, one_default_month, two_default_day and two_default_month.
		  This allows the caller to determine whether or not the code inserted a day
		  and/or month into an incomplete date. Years are never inserted into dates.
		  This matches a feature available in Gedcom::Date, but with a completely
		  different implementation.
		o There is a new parameter 'style' passable into new() and the parse_*() methods.
		  It takes the values 'american', 'english' and 'standard', to allow the code
		  to expect dates formatted in various ways. The parameter is not called
		  format because I have plans to use format as the name for a parameter which
		  will allow to user to specify the output format of the dates.
		  american => Expect 'month day year', as in From Jan 2 2011 BC to Mar 4 2011.
		  english  => Expect 'day month year', as in From 1 Jan 2001 to 25 Dec 2002.
		  standard => Expect 'year month day', as in From 2011-01-02 to 2011-03-04.
		  See t/style.t for sample code.
		o Gregorian is the only supported date escape. Every date escape triggers
		  processing using Gregorian month names and abbreviations.
		o DateTime::Format::Natural is no longer used. Instead, the incoming date is
		  split on [ -\/] rather than just [ -], and this module tries to parse it.
		o All commas are deleted from incoming dates.
		o BC may be written as BCE.
		o Some dates which are not ambiguous, e.g. 2011-01-01, were wrongly flagged
		  as ambiguous. Thanx to Eugene van der Pijll for alerting me to this bug.