"Kevin McArthur" <Kevin@StormTide.ca> writes:
> My vote is that you guys drop timetz completely.
I can already give you the final score on that one:
SQL standard 1, Kevin 0
The problem here is the same old bugaboo that the standard pretends
daylight-savings time doesn't exist. So we are in the standards
extension business to try to find semi-reasonable semantics for the
standard datatypes when faced with DST-aware timezone definitions.
But dropping a type required by the spec isn't going to happen.
I can however see a good argument for rejecting DST-dependent input
for timetz. We aren't required by the spec to accept that, and as
Kevin says it's just not well defined.
There was talk awhile ago of storing actual timezone identifiers of
some kind in timestamptz and timetz values. If that ever gets done
then I think '16:40 America/New_York' would be a useful value of
timetz --- for instance, "date plus timetz" could yield a meaningful
timestamptz. But given our current limited implementation of timetz,
there's a lot to be said for rejecting DST-dependent input.
regards, tom lane
