On 10/9/07, Peter Eisentraut <peter_e@gmx.net> wrote:
> Independent of what any specification might say, however, the currently
> implemented behavior is clearly wrong in my mind and needs to be fixed.
I don't think it's wrong, just a particular choice. As an example,
consider an interval scheduling system that handles everything in
absolute time (UTC), but uses local time as a convenience. Perhaps it
presents a timestamp a few months from now to the user, and accepts
any stamp back in the user's timezone. When the DST rules suddenly
change a couple weeks before that timestamp occurs, you don't want the
database changing its interpretation of what was entered months ago;
the absolute time is already the correct time.
That's simply a specific version of the general case of wanting the
database to operate in absolute time, and present local time as a user
convenience. Conveniently, PostgreSQL does exactly that now.
If that behavior changes, making the above work anyway is easy:
explicitly convert to UTC on input. But that's just a counterpoint to
what I mentioned earlier in the thread, explicit conversion of local
times. Either way, someone has to do some work to adapt to their
specific usage, so which method the database naturally uses is just an
arbitrary choice.
FWIW, I am in favor of having it [behave as if it does] store the
literal time and its associated zone. To me that seems smart,
consistent, and more likely to fit what people need. I don't see it
as fixing wrong behavior, though.