Re: Should we throw error when converting a nonexistent/ambiguous timestamp? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should we throw error when converting a nonexistent/ambiguous timestamp?
Date
Msg-id 27156.1268701973@sss.pgh.pa.us
Whole thread Raw
In response to Should we throw error when converting a nonexistent/ambiguous timestamp?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should we throw error when converting a nonexistent/ambiguous timestamp?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm starting to think that maybe we should throw error in these cases
>> instead of silently doing something that's got a 50-50 chance of being
>> wrong. �I'm not sure if the "assume standard time" rule is standardized,
>> but I think it might be better if we dropped it. �Thoughts?

> That seems overly picky and fairly pointless to me.  Generally I'm a
> big fan of the idea that obvious breakage is better than silent
> breakage, but in this case it seems highly likely that you'll still
> have silent breakage until such time as a time change rolls around.

Yes, that's true, the failure will only be apparent when a DST
transition is sufficiently close by.  However, the problem with the
current behavior is that the failure isn't obvious even then ---
you might not notice the data inconsistency until much later when
it's not possible to sort things out.

The current code behavior seems to me to be on par with, for example,
trying to intuit MM-DD versus DD-MM field orders.  We used to try to
do that, too, and gave it up as a bad idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Takahiro Itagaki
Date:
Subject: Re: Ragged latency log data in multi-threaded pgbench
Next
From: Robert Haas
Date:
Subject: Re: Should we throw error when converting a nonexistent/ambiguous timestamp?