>>>>> "Jim" == Jim Faucette <jimf@stripped> writes:
Jim> Quang D. Nguyen wrote:
>>
>> On Sat, 29 May 1999, Paul DuBois wrote:
>>
>> >
>> > What result are you expecting?
>>
>> 0000-00-00 like if you insert .. values ('1999-12-35');
>> How do you think about that? If MySQL do not able to manage this problem,
>> how can it manage the Y2K-t? I think this is more simple than other.
>>
Jim> Data entry exception coding is not the same as the Y2K storage issue.
Jim> I do agree that MySQL's handling of date entries is not consistant. The
Jim> developers' position is that exception coding should be the users
Jim> responsibility. If MySQL did NO date range checks on date entries
Jim> (instead of the few it does now), then maybe this question would stop
Jim> being asked so often.
Jim> So 19991299 would be accepted just as 19990231 is now.
The problem is that MySQL can't store dates with day > 31
MySQL store date columns packed as follows:
day: 5 bits Possible values: 0-31
month: 4 bits; Possible values: 0-15
year: 14 bits; Possible values 0-9999
This is saved in a 24 bit integer. This make it impossible to store
any wrong date; MySQL only checks that the day <= 31 and month <= 12
to ensure that one doesn't get completely wrong dates because of the
above packing.
Regards,
Monty
