Re: A creepy story about dates. How to prevent it?

Reading the subject, "creepy ... dates", that is exactly how I feel
about the described current date behavior --- "creepy".

Because I have only seen one person defend our current behavior, and
many object, I am going to add to TODO:

	* Allow current datestyle to restrict dates;  prevent month/day swapping
          from making invalid dates valid
	* Prevent month/day swapping of ISO dates to make invalid dates valid

I know someone was mentioning how bad it was that MySQL allows NULL in a
NOT NULL date field, and inserts 00-00-0000.  I think we are pretty
close to that with our current behavior.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > It would make sense to offer a "strict" mode in which the date order
> > has to be what DateStyle suggests.  I'm astonished that no one seems
> > to get the point that there are also good uses for "lax" parsing.
> 
> There are different kinds of lax parsing.
> 
> Lax parsing is great if you can enter any of
> 
> January 8, 1999
> 1999-01-08
> 1/8/1999
> 990108
> January 8 04:05:06 1999 PST
> 
> and it will know what you mean, because of all these have their uses and
> are unambiguous (given a known day/month order).
> 
> But automatically switching the declared day/month order based on
> heuristics is not that great.  A human is not going to mentally switch his
> preferred day/month order within the same SQL session.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073