Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster