There appear to be several bugs in the at time zone patch recently applied.
show timezone;
TimeZone
----------
UTC
(1 row)
select now();
now
-------------------------------
2005-07-20 23:38:57.981128+00
(1 row)
*** WORKS ***
select CURRENT_DATE + '05:00'::time at time zone 'Canada/Pacific';
?column?
------------------------
2005-07-21 05:00:00+00
(1 row)
*** BROKEN ***
select (CURRENT_DATE + '05:00'::time)::timestamp at time zone 'Canada/Pacific';
timezone
------------------------
2005-07-19 22:00:00+00
(1 row)
Wrong date _and_ time. (Ive not even got a theory about how the date gets wrong here)
select '05:00'::time at time zone 'Canada/Pacific';
timezone
-------------
22:00:00-07
(1 row)
Wrong time.
I think there's something fishy going on with internal casts.
if time has no timezone it should not imply a cast to timetz using the local timezone, instead time to at time zone should ADD timezone information to the datatype to result in a timetz though that may require the use of something like select '05:00'::time at time zone 'Canada/Pacific' on CURRENT_DATE::date to do properly.
Suggested resolution would be to allow the actual storage of named timezone descriptions like 'Canada/Pacfiic' within the timetz datatype natively instead of converting to utc for storage (which is logically invalid).
The application of this whole problem is for a VoIP network to be able to handle evening and weekend calling based on cities. Evening being after 6pm in vacouver per se. Current and historical processing of the time zone data is also a requirement.
Hope that helps.
Kevin McArthur
Director
StormTide Digital Studios Inc.
