Re: Datetime patch

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> INSERT INTO TIMESTAMP_TBL VALUES ('97/02/10 17:32:01 UTC');
> >> + ERROR:  Bad timestamp external representation '97/02/10 17:32:01 UTC'
>
> > Again, this one should fail.
>
> It should?  I think you're gonna have a lot of unhappy users if there's
> no way to persuade Postgres to take that.  This is the same point we
> were discussing on the phone earlier.
>
> It might be that the cleanest way to do things is to extend the
> input-side DateStyle to a three-way switch, "US" (accept mm/dd/yy)
> "Euro" (accept dd/mm/yy) and a third case that accepts yy/mm/dd.
> But I do not believe we can get away with deciding that common date
> formats aren't common.

I have never seen YY/MM/DD, only YYYY-MM-DD.  The huge problem is
deciding out how to decode 03-02-01.  I think we have to require the
century for those.  The big point is that yy-mm-dd only works for years
> 31.  For current dates, you can't specify it because it is already
taken as month first or day first, so I don't see how anyone could be
already using such a format for input.

If we go with a three-way, I am afraid things get confusing because you
have a xx/xx/xx date input that is year first, while I think we have to
insist on xxxx/xx/xx for dates.  We can try it and see what reports we
get.  I don't even know what we would call such a three-way because I
have never seen dates in that format.

If that is the only issue, I can ask on general, but I doubt someone is
going to pipe up.

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