Thread: Timezone bugs

My guess is that is this commit that is causing the problem:
revision 1.110date: 2005/06/15 00:34:08;  author: momjian;  state: Exp;  lines: +48 -40This patch makes it possible to
usethe full set of timezones when doing"AT TIME ZONE", and not just the shorlist previously available.
Forexample:SELECTCURRENT_TIMESTAMP AT TIME ZONE 'Europe/London';works fine now. It will also obey whatever DST rules
werein effect atjust that date, which the previous implementation did not.It also supports the AT TIME ZONE on the
timetzdatatype. The wholehandling of DST is a bit bogus there, so I chose to make it use whateverDST rules are in
effectat the time of executig the query. not sure ifanybody is actuallyi *using* timetz though, it seems
prettyunpredictablejust because of this...
 
Magnus Hagander

I will research it tomorrow and report back.

---------------------------------------------------------------------------

Kevin McArthur wrote:
> 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
shouldADD 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
thetimetz 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.
> 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Kevin McArthur wrote:
> 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)

OK.

> *** 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)

What is happening here is that 2005-07-20 05:00:00 is being cast back 7
hours (Canada/Pacific offset), and that is 22:00 of the previous day.

> 
> 
> select '05:00'::time at time zone 'Canada/Pacific';
>   timezone   
> -------------
>  22:00:00-07
> (1 row)
> 
> Wrong time.

Well, again 5am GMT is 22:00 Canada/Pacific, no?

---------------------------------------------------------------------------


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

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

On Jul 21, 2005, at 11:57 PM, Bruce Momjian wrote:
>    works fine now. It will also obey whatever DST rules were in  
effect at>    just that date, which the previous implementation did not.

Speaking of that, would the nearly passed US bill to extend daylight  
savings screw up our timezone & dst things?

http://usgovinfo.about.com/od/consumerawareness/a/dstextend.htm

(nutshell summary: DST would be changed from april-oct to mar-nov)

afaik it has passed the house & senate it just needs the prez to sign  
it.
--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/

Jeff Trout wrote:
> 
> On Jul 21, 2005, at 11:57 PM, Bruce Momjian wrote:
> 
>  >    works fine now. It will also obey whatever DST rules were in  
> effect at
>  >    just that date, which the previous implementation did not.
> 
> Speaking of that, would the nearly passed US bill to extend daylight  
> savings screw up our timezone & dst things?
> 
> http://usgovinfo.about.com/od/consumerawareness/a/dstextend.htm
> 
> (nutshell summary: DST would be changed from april-oct to mar-nov)
> 
> afaik it has passed the house & senate it just needs the prez to sign  
> it.

It means we would have to update our timezone database, and perhaps
backpatch the fix to 8.0.X.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

On 2005-07-22, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>> 
>> select (CURRENT_DATE + '05:00'::time)::timestamp
>>    at time zone 'Canada/Pacific';
>>         timezone        
>> ------------------------
>>  2005-07-19 22:00:00+00
>> (1 row)
>> 
> What is happening here is that 2005-07-20 05:00:00 is being cast back 7
> hours (Canada/Pacific offset), and that is 22:00 of the previous day.

Which is of course completely wrong.

Let's look at what should happen:
(date + time) = timestamp without time zone

'2005-07-20' + '05:00' = '2005-07-20 05:00:00'::timestamp
(timestamp without time zone) AT TIME ZONE 'zone'

When AT TIME ZONE is applied to a timestamp without time zone, it is
supposed to keep the _same_ calendar time and return a result of type
timestamp with time zone designating the absolute time. So in this case,
we expect the following to happen:
'2005-07-20 05:00:00'              (original timestamp)-> '2005-07-20 05:00:00-0700'      (same calendar time in new
zone)->'2005-07-20 12:00:00+0000'      (convert to client timezone (UTC))
 

So the conversion is being done backwards, resulting in the wrong result.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services