Hi Lester, On Fri, Feb 13, 2015 at 6:52 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Management of dates is controversial in a lot more areas than just using > the wrong calendar in prior times ;) > Each database uses it's own way to handle dates and time internally, and > most default actions are different, add to which using second as the > base for dates is just wrong anyway, but we have to live with what is > currently available. > The area that needs fixing first is the underlying OS functions rather > than continually trying to patch the top level, but we perhaps need to > document better just where the joins are ... just how many days were > there from 0BC to today ... > I agree. Under MySQL, these strange results from DateTime class would not be stored because MySQL does not handle year less than 1000. Under PostgreSQL, datetime types support 4713 BC to 294276 AD. In addition, PostgreSQL is smart enough that convert 2015-01-32 to 2015-02-01, 0000-00-00 to 0001-01-01 BC, etc. Therefore, these results will be stored as _valid_ date. This is really bad... All invalid date should be invalid. The only possible exception may be 0000-00-00, since many users may rely on this behavior under MySQL. We have exception for unserializing 0000-00-00, though. Anyway, we need DataTime expert here. What do you think Derick? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
