Randall Nortman <postgreslists@wonderclown.com> writes:
> On Sun, Oct 31, 2004 at 02:44:51PM -0500, Tom Lane wrote:
>> Actually, the intended and documented behavior is that it should
>> interpret an ambiguous time as local standard time (e.g., EST not EDT).
> I'm finding it hard to see how either way is likely to generate good
> results in *any* application, much less in a majority of applications.
> So in a way, perhaps the most correct thing to do would be to spit out
> an error if the timestamp is ambiguous. Any application which deals
> with timestamps in anything other than UTC should really be handling
> the disambiguation itself, because the server can't possibly know what
> the application means to do. Not generating an error is likely to
> allow an application bug to go unnoticed, especially if the database
> does not have a unique constraint on timestamps (as mine does).
That line of argument leads directly to the conclusion that we shouldn't
allow timezone-less input strings at all, since it's unlikely that
anyone would code their app to append a timezone spec only during the
two hours a year when it actually matters. And wouldn't you rather have
had the problem pointed out immediately on testing the app, rather than
waiting till 1AM on a fall Sunday morning to find out it's broken?
However, I am not prepared to buy into requiring explicit TZ specs
always... it's just too much of a PITA.
For human users, there would be some value in acting this way, since
it would serve to remind them of the issue only when it actually
matters. Comments anyone?
regards, tom lane