[ Moved to hackers.] (The discussion is whether we should support dates of the format yy-mm-dd. We already support yyyy-mm-dd, but we have code that would see 97-01-01 and detect the first part was a year.)
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have never seen YY/MM/DD, only YYYY-MM-DD. > > You have apparently forgotten what was standard practice just a few > years ago. Well, seeing as it hasn't worked for a date in three years, I don't see how anyone could be using it unless they are only entering dates per-2000, which seems unlikely. It will be come useful again in 2032. > > The huge problem is > > deciding out how to decode 03-02-01. I think we have to require the > > century for those. > > No, the entire point is to drive it off datestyle, *not* off the input > value ranges. If they supply a four-digit year, we assume yyyy-mm-dd, if not we follow datestyle. I can see someone wanting yy-mm-dd, but then we need a _new_ setting to control that, because the detection code for a year being > 31 just doesn't work in 2003. I see what you are saying, that using the four-digit leading as specifying a year is arbitrary, but it does allow us to accept both ISO and US/European dates cleanly. I guess the question is whether it is worth allowing yy-mm-dd using a _new_ setting. I still think we will need the 4-digit rule for ordinary users. The driving thing here was consistency, so the same session didn't accept 19-8-03 and 8-19-03 while other dates like 01-01-03 were following datestyle. I don't see how the 4-digit rule actually is inconsistent in that way. > > If that is the only issue, I can ask on general, but I doubt someone is > > going to pipe up. > > I really dislike the idea that we are going to legislate this behavior > in a three-person discussion on -patches. The people who will be > screaming about it don't read -patches. I would be shocked to find someone screaming. I have asked on general, and if someone come up with a valid use for it, we can adjust it, even during beta. We can't tighten during beta, but we can loosen. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html