Re: A creepy story about dates. How to prevent it?

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <cmarin(at)dims(dot)com>, "Pgsql-General-post (E-mail)" <pgsql-general(at)postgresql(dot)org>
Subject: Re: A creepy story about dates. How to prevent it?
Date: 2003-06-19 14:06:17
Message-ID: Pine.LNX.4.33.0306190804300.7044-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 18 Jun 2003, Tom Lane wrote:

> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > On Wed, 18 Jun 2003, Tom Lane wrote:
> >> I do now seem to recall an agreement that a GUC switch to disable
> >> date-interpretation guessing would be okay, though.
>
> > I'm pretty sure it was the other way around, make strict locale / date
> > checking the standard and a GUC to turn it off for folks who really want
> > to use a broken database. :-)
>
> This is definitely a case where what is "broken" is in the eye of the
> beholder. If the current behavior is broken, why have we had so few
> complaints about it? It's been like that for quite a few years now.
>
> I think that on grounds of backwards compatibility alone, we should
> leave the out-of-the-box default behavior as it is.

I thought of another "silent failure" scenario.

Imports. If you have say 10,000 rows to import, and all the dates are in
euro style format going into a us style database, then all the ones where
the "month" is <13 will be put in wrong, and all the ones with a "month"
>12 will be silently converted to be right. Now half the dates are right,
and half are wrong, and there's no error.

That's the worst of possibilities. Better to fail grandly than silently
corrupt data.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Stark 2003-06-19 14:08:24 Re: Incremental backups, and backup history
Previous Message Nigel J. Andrews 2003-06-19 14:01:38 Re: why are my SELECTs in transaction?