Re: Should we throw error when converting a nonexistent/ambiguous timestamp?

On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

I disagree. Even if the application DOES record a wrong time-stamp,
it's likely to be wrong by exactly an hour, or say two hours, and it
may well be possible to reconstruct what should have happened later;
an application crash may be result in no data being recorded at all,
and may therefore be harder to recover from. Alternatively the
timestamp may be used for something non-critical, like logging a
last-changed time, and now you've turned a minor inaccuracy into an
application crash. The scenario you describe is possible too, but
it's not clear-cut. If we were starting from scratch I think either
behavior would be defensible, but changing it now doesn't seem good to
me.

> 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.

I suppose it's topologically equivalent, but to me that is an order of
magnitude crazier than this case.

Of course I may be in the minority... but you did ask...

...Robert