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

2010-03-15 Thread Tom Lane
Robert Haas writes: > On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane 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, >>

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

2010-03-15 Thread Tom Lane
Robert Haas writes: > On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane wrote: >> 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 eq

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

2010-03-15 Thread Robert Haas
On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane 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

[HACKERS] Should we throw error when converting a nonexistent/ambiguous timestamp?

2010-03-15 Thread Tom Lane
It's DST transition season again, and that means that we're getting the usual quota of questions from people who don't quite understand how DST-related timestamp arithmetic works, and whose incorrect code seems to work until exercised during a transition interval. We've got this one from a guy who