Re: Using YY-MM-DD date input

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I see this as a feature addition, because right now, in 2003, there is
> > no way to enter a current date with a leading year using only two digits.
>
> How can you say that, when there is a regression test that proves it
> works (and always has worked)?

I said "no way to enter a current date":

> > no way to enter a current date with a leading year using only two digits.

^^^^^^^^^^^^^^

It might work, but do we want it to work in 2003. I say no, just like
we don't want to arbitrarily guess which is the day and which the month.

You haven't told me how anyone is using yy-mm-dd for date input in 2003,
so removing it doesn't seem like a big deal to me.

> >> There are presently only two input DateStyles ('US' and 'European') but
> >> it would be trivial to add a third to accept yy-mm-dd. We'd only need
> >> to figure out what to call it. I'm tempted to just call it 'YMD' and
> >> provide 'DMY' and 'MDY' as alternative names for 'US' and 'European'.
>
> > Now, that is an interesting idea, and I wonder if they aren't better
> > than US and European (and German), because they are more general.
>
> I'm envisioning these as determining the input interpretation only.
> The output formatting choices are a distinct set. (It was a bad idea to
> overload DateStyle to contain two separate settings, but we're probably
> stuck with that for now.) But yes, I could easily be talked into making

It would be nice to specify the input and output formats independently.
I think we can sort of do that now, but it isn't clear. When format is
Postgres, US/European control whether month is first in input and
output. When it is ISO, the US/European only controls input for non-ISO
dates. It isn't very clear, but does hit the common uses.

One problem with a YMD format specification is that it isn't clear that
that applies only to two-digit years because ISO is already YMD. I
wonder if we have to call them YYMMDD, MMDDYY, and DDMMYY.

> these names be the standard ones. Right now would be the time to do it,
> since we're already changing the output format of "SHOW DATESTYLE"; if
> we wait a cycle then we'll be churning that API twice in a row.

Oh, good point. I had forgotten about that.

> > Is this something we want to do in feature freeze?
>
> I think it's a necessary part of the already-proposed patch to tighten
> input date interpretation. Now personally I'd be quite happy to put off
> that whole affair for 7.5, because I don't think it's been thought
> through adequately. But if you want to complete that open item in this
> cycle, then I think we have to follow it out to the logical conclusions.
> You can't arbitrarily decide to remove functionality and not put a
> substitute in place just because we're past feature freeze. (A freeze
> extends to not removing stuff, as well as not adding stuff, IMHO.)

His patch came in before feature freeze. We are only addressing it in
feature freeze.

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