| From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, Michal Kalanski <kalanskim(at)zetokatowice(dot)pl>, <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Dates in inserts |
| Date: | 2003-04-01 17:26:27 |
| Message-ID: | Pine.LNX.4.33.0304011026040.13402-100000@css120.ihs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, 1 Apr 2003, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> > Probably becuase there is no 13th month so 01.13.03 can only be
> > interpreted as the 13th of January.
>
> Right, and the same goes for 13.01.03: even if your datestyle is mmddyy,
> the date parser will take this as ddmmyy, because otherwise it couldn't
> be valid. AFAIK there is no way to force the date parser to reject the
> input instead. Datestyle is used to drive the interpretation when the
> input is ambiguous, but not when there is only one interpretation that
> will work.
>
> If you prefer to be stiff-necked then I'd recommend putting some
> validation on the client side.
I think the better answer is to only insert dates in an unambiguous
format.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2003-04-01 18:27:35 | Re: Cursors with Large, Ordered Result Sets |
| Previous Message | Bruce Momjian | 2003-04-01 17:18:27 | Re: Log the SQL Statements |