-----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

Reply via email to