Skip site navigation (1) Skip section navigation (2)

Re: Daylight Savings Time handling on persistent connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Randall Nortman <postgreslists(at)wonderclown(dot)com>,pgsql-general(at)postgresql(dot)org
Subject: Re: Daylight Savings Time handling on persistent connections
Date: 2004-10-31 22:55:23
Message-ID: 2244.1099263323@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Responses

pgsql-general by date

Next:From: Bruce MomjianDate: 2004-11-01 04:52:37
Subject: Re: PostgreSQL on Windows
Previous:From: Martijn van OosterhoutDate: 2004-10-31 22:42:42
Subject: Re: Daylight Savings Time handling on persistent connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group