On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
