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
