On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
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