Re: Using YY-MM-DD date input

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@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