-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> This cannot be right can it? The code used to check EuroDates and now > it doesn't. ISTM you must have broken either Euro or US format. I'm not sure of the final consensus on what exactly the behavior should be. > Also, I thought that the consensus on -general was that the heuristics > involving looking at the range of the values were a bad idea. (While > I disagree, I can recognize a lost cause when I see one.) You've still > got them in there. ISTM the code ought to assume MM before DD if ISO > or Euro style, otherwise (US style) assume DD before MM, and then reject > if out of range, rather than allowing the range to determine which is > which. The ranges are only in there as an earlier catch of an invalid date - they no longer are part of the earlier logic which allowed a "pass-through." They should be removeable with no effect. I'll write up a new patch. Does this logic seem correct? if (US) { YYYY-MM-DD MM-DD-YYYY } else { YYYY-MM-DD DD-MM-YYYY } In other words, the US is backwards from the rest of the world. (as far as MM-DD-YYYY) Thanks, - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306251031 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE++bdlvJuQZxSWSsgRArcZAKD4+VO8yK6LeOYszPHL9Kp2Ol4HaQCg4Ovf wv8M/bvlzeACu6/ow8RpvoQ= =Dgns -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match