> Yes it does, for ambiguous cases such as yours.
Which means that independent of the date style, it should give a date error
either way?
> I'm willing to bet that the date style is *not* set to "European".
> Please demonstrate with a "show datestyle" and "select date
> '2.10.1997'"...
NOTICE: DateStyle is ISO with European conventions.
?column?
-----------
1997-10-02
Seems to be a problem with inserting reversed dates (Eg. 1997.13.2) and
invalid dates...
Inserting 10.13.1997:
gives 'Bad external date representation 10.13.1997' - correct
Inserting '19.13.2':
gives '2013-02-19' (dd.yy.mm ??? ) - not exactly what I hoped
:)
Unfortunately I am inserting 20,000 dates into a table, so it is not a one
off case.
Is there any way to enforce specific date formats without the parser
calculating the 'best-fit' case?
Chris
----- Original Message -----
From: "Thomas Lockhart" <lockhart@alumni.caltech.edu>
To: "Chris Storah" <cstorah@e-mis.com>
Cc: <pgsql-bugs@postgresql.org>
Sent: Friday, April 27, 2001 5:04 PM
Subject: Re: 7.1 euro-style dates insert error
> > Automatically thinks that the last value is a US style date.
> > Date style is set to EURO, but I assume this has no affect on the date
> > parsing at insert time.
>
> Yes it does, for ambiguous cases such as yours.
>
> > If the dates are entered as 'ccyy.mm.dd' it is okay - unfortunately
> all my
> > dates are in the format 'dd.mm.ccyy'.
> > Is this a bug or a user error?
>
> I'm willing to bet that the date style is *not* set to "European".
> Please demonstrate with a "show datestyle" and "select date
> '2.10.1997'"...
>
> - Thomas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
