Re: Daylight Savings Time handling on persistent connections

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sun, Oct 31, 2004 at 04:14:52PM -0500, Tom Lane wrote:
>> 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.

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

> Except that means your program will work all the time except for one or
> two hours per year where it breaks. Chances are your testing is not
> going to trip it...

ISTM basically we have to make a tradeoff between convenience for
human-driven data entry and reliability for program-driven data entry.
Refusing TZ-less data input would certainly force programmers to write
their programs more safely, but is it worth the inconvenience for
interpreting human-generated input strings?  I doubt it.  We already
allow a great variety of input syntaxes, some would say more than we
should, in order to make the timestamp input converters useful for
interpreting hand-entered strings.

I'm inclined to think that rejecting impossible or ambiguous input
without a zone is reasonable (and it would go along with the changes
we made in 7.4 to tighten up datetime field order assumptions).
But I don't want to take away the convenience of leaving off the
zone altogether.

One point here is that timestamp-to-timestamptz datatype conversion will
be affected by whatever we choose.  While it's easy to say "reject it"
for data coming into a database, it's less easy to say that a coercion
function should fail on some inputs it didn't use to fail on.

            regards, tom lane