On Sun, Feb 24, 2013 at 11:10:24AM +0000, Ian Goddard wrote: >Martin Steer wrote: >> >>> And the mention of January 1662-3 above should be a hint that dates are >>> another can of worms better dealt with by an OO approach >> >> Given that dates are just data, I don't get this. You'll have to tell me >> why this is so. > >1. The above date is prior to the adoption of Gregorian dates in England >& her colonies. The year, especially in church usage, was often taken >as starting on March 25th. Sometimes the first three months are simply >given as being in the same year as the preceding December (1662 in the >above case), sometimes with a dual year as above and sometimes as >new-style dates (1663 in my example). Conventional RDBMS only deals >with the new-style (hopefully it will also know about September 1752 - >run cal if you don't know about that one). Thanks for that. I was aware of this as an issue when I first started experimenting, but haven't thought much about it since. I store the date the source gives me, as a text string, e.g. '14 Sep 1752', '1842 Q3'. I'm not a fan of software that insists I break information into little bits, whether I want to or not. The database has a trigger function to also store a date-span, so: 14 Sep 1752 -> [1752-09-14][1752-09-14] from 1852 to 1900 -> [1852-01-01][1900-12-31] The data is in the text string, the spans are useful for calculations, searching, and sorting of events or records, etc. If I think of something cleverer later on, I can recalculate the spans. M.