Thread: Day Light Savings Problem
Hi, As per this article http://people.planetpostgresql.org/greg/index.php?url=archives/96-Is-your-database-ready-for-the-Daylight-Savings-Times-change-of-2007.html&serendipity[cview]=linear#comments, My postgres 8.0.2 database has a problem with the new day light savings time change this month. So, I upgraded it to the latest 8.0 version which is 8.0.12 and below you will see the output of the case statement and also the timezone file. As you can see the case statement says that timezone value is fixed but where as the timezone file still has the old values. Is this a bug ? why cant it show the new timezone values in the timezone file ? I even looked at the 8.2.1 timezone file it also has the old values. Can I use this postgres 8.0.12 version for the day light savings problem. =========================================================== postgres@pkalva:/var/lib/pgsql/bin> ./psql template1 Welcome to psql 8.0.12, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit template1=# SET TIMEZONE = 'EST5EDT'; SET template1=# template1=# SELECT CASE WHEN template1-# timestamptz '20070401 0100' template1-# + interval '1 hour' template1-# >= '20070401 0300' template1-# THEN 'Wrong' ELSE 'Right' END; case ------- Right (1 row) template1=# \q postgres@pkalva:/var/lib/pgsql/bin> cd .. postgres@pkalva:/var/lib/pgsql> cd share postgres@pkalva:/var/lib/pgsql/share> /usr/sbin/zdump -v EST5EDT | grep 2007 EST5EDT Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST isdst=0 gmtoff=-18000 EST5EDT Sun Apr 1 07:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000
Pallav Kalva <pkalva@livedatagroup.com> writes: > postgres@pkalva:/var/lib/pgsql/bin> cd .. > postgres@pkalva:/var/lib/pgsql> cd share > postgres@pkalva:/var/lib/pgsql/share> /usr/sbin/zdump -v EST5EDT | grep 2007 > EST5EDT Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST > isdst=0 gmtoff=-18000 Are you sure that zdump looks into the current directory? The man page is not clear but it says the arguments are "zone names" not "file names", so I'd sort of expect that it's looking into the system timezone directory. In which case this result means that your OS is in need of a timezone update, not Postgres. regards, tom lane
Hi Tom, You are right , I re reran the command now with the whole path it worked. It was looking at the OS time ======================================================================================== postgres@pkalva:/var/lib/pgsql/share/timezone> /usr/sbin/zdump -v /var/lib/pgsql/share/timezone/EST5EDT | grep 2007 /var/lib/pgsql/share/timezone/EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000 /var/lib/pgsql/share/timezone/EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400 /var/lib/pgsql/share/timezone/EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400 /var/lib/pgsql/share/timezone/EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000 ======================================================================================== Thanks! Pallav Tom Lane wrote: > Pallav Kalva <pkalva@livedatagroup.com> writes: > >> postgres@pkalva:/var/lib/pgsql/bin> cd .. >> postgres@pkalva:/var/lib/pgsql> cd share >> postgres@pkalva:/var/lib/pgsql/share> /usr/sbin/zdump -v EST5EDT | grep 2007 >> EST5EDT Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST >> isdst=0 gmtoff=-18000 >> > > Are you sure that zdump looks into the current directory? The man page > is not clear but it says the arguments are "zone names" not "file names", > so I'd sort of expect that it's looking into the system timezone > directory. In which case this result means that your OS is in need of > a timezone update, not Postgres. > > regards, tom lane >