Обсуждение: Weird new time zone
How come I default to Antartica in CVS? test=# show time zone; TimeZone ------------------ Antarctica/Casey (1 row) test=# Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> How come I default to Antartica in CVS?
You tell us ... what's your real timezone, and what do you get from
pushing up the log level to DEBUG4 during postmaster start?
regards, tom lane
> You tell us ... what's your real timezone, and what do you get from > pushing up the log level to DEBUG4 during postmaster start? OK, I have log level set to debug4 and australian_timezones set to true. The system time zone is set to WST. Attached is the startup log. I should point out that the Casey Antarctic base is in the Australian Antarctic Territory and it is in the same time zone as Perth, Western Australia for me: http://times.clari.net.au/location.php3/Antarctica/Casey http://times.clari.net.au/location.php3/Australia/Perth So I guess in many ways, PostgreSQL is correct - just...weird... I should also point out that with australian_timezones set to false, it still picks Casey Station in Antarctica. Chris postmaster starting DEBUG: Reject TZ "Africa/Algiers": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Luanda": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Porto-Novo": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Gaborone": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Ouagadougou": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Bujumbura": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Douala": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Bangui": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Ndjamena": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Kinshasa": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Lubumbashi": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Brazzaville": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Abidjan": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Djibouti": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Cairo": at 1089417600 2004-07-10 03:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Malabo": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Asmera": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Addis_Ababa": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Libreville": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Banjul": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Accra": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Conakry": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Bissau": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Nairobi": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Maseru": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Monrovia": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Tripoli": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Blantyre": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Bamako": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Timbuktu": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Nouakchott": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Casablanca": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/El_Aaiun": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Maputo": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Windhoek": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Niamey": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Lagos": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Kigali": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Sao_Tome": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Dakar": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Freetown": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Mogadishu": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Johannesburg": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Khartoum": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Mbabane": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Dar_es_Salaam": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Lome": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Tunis": at 1089417600 2004-07-10 01:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Kampala": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Lusaka": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Harare": at 1089417600 2004-07-10 02:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Africa/Ceuta": at 1089417600 2004-07-10 02:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Cape_Verde": at 1089417600 2004-07-09 23:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/St_Helena": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Faeroe": at 1089417600 2004-07-10 01:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Reykjavik": at 1089417600 2004-07-10 00:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Azores": at 1089417600 2004-07-10 00:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Madeira": at 1089417600 2004-07-10 01:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Canary": at 1089417600 2004-07-10 01:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Bermuda": at 1089417600 2004-07-09 21:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Stanley": at 1089417600 2004-07-09 20:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/South_Georgia": at 1089417600 2004-07-09 22:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Atlantic/Jan_Mayen": at 1089417600 2004-07-10 02:00:00 dst versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Comoro": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Antananarivo": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Mauritius": at 1089417600 2004-07-10 04:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Mayotte": at 1089417600 2004-07-10 03:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Reunion": at 1089417600 2004-07-10 04:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Mahe": at 1089417600 2004-07-10 04:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Kerguelen": at 1089417600 2004-07-10 05:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Chagos": at 1089417600 2004-07-10 06:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Maldives": at 1089417600 2004-07-10 05:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Christmas": at 1089417600 2004-07-10 07:00:00 std versus 2004-07-10 08:00:00 std DEBUG: Reject TZ "Indian/Cocos": at 1089417600 2004-07-10 06:30:00 std versus 2004-07-10 08:00:00 std DEBUG: Accept TZ "Antarctica/Casey" DEBUG: postmaster: PostmasterMain: initial environ dump: DEBUG: ----------------------------------------- DEBUG: USER=chriskl DEBUG: SSH_CLIENT=192.168.0.1 2818 22 DEBUG: MAIL=/var/mail/chriskl DEBUG: SHLVL=1 DEBUG: HOME=/home/chriskl DEBUG: OLDPWD=/home/chriskl/pgsql DEBUG: SSH_TTY=/dev/ttyp0 DEBUG: LOGNAME=chriskl DEBUG: _=/home/chriskl/local/bin/pg_ctl DEBUG: BLOCKSIZE=K DEBUG: TERM=xterm DEBUG: PGSYSCONFDIR=/home/chriskl/local/etc/postgresql DEBUG: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/chriskl/bin:/home/chriskl/local/bin DEBUG: SHELL=/usr/local/bin/bash DEBUG: PWD=/home/chriskl/pgsql-server DEBUG: SSH_CONNECTION=192.168.0.1 2818 192.168.0.8 22 DEBUG: PGDATA=/home/chriskl/local/data DEBUG: FTP_PASSIVE_MODE=YES DEBUG: ----------------------------------------- DEBUG: invoking IpcMemoryCreate(size=9691136) DEBUG: max_safe_fds = 984, usable_fds = 3169, already_open = 6 LOG: database system was shut down at 2004-07-10 16:07:37 WST LOG: checkpoint record is at 0/A37F6C LOG: redo record is at 0/A37F6C; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 496; next OID: 17228 LOG: database system is ready DEBUG: proc_exit(0) DEBUG: shmem_exit(0) DEBUG: exit(0) DEBUG: reaping dead processes
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Attached is the startup log. I should point out that the Casey
> Antarctic base is in the Australian Antarctic Territory and it is in the
> same time zone as Perth, Western Australia for me:
Looking in the data files,
Zone Antarctica/Casey 0 - zzz 1969 8:00 - WST # Western (Aus) Standard Time
Zone Australia/Perth 7:43:24 - LMT 1895 Dec 8:00 Aus WST 1943 Jul 8:00 - WST
1974 Oct lastSun 2:00s 8:00 1:00 WST 1975 Mar Sun>=1 2:00s 8:00 - WST 1983 Oct
lastSun2:00s 8:00 1:00 WST 1984 Mar Sun>=1 2:00s 8:00 - WST 1991 Nov 17 2:00s
8:00 1:00 WST 1992 Mar Sun>=1 2:00s 8:00 - WST
which if I recall the notation right says that Casey has never observed
DST (it's always GMT+8 == WST) while Perth has observed DST in just
three years since WWII. So unless the timezone probing code happens to
check those particular years, we have no chance of distinguishing the
two zones.
Perhaps, rather than just probing a few selected years, we had better
check every year since 1970 ...
regards, tom lane
On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote: > Perhaps, rather than just probing a few selected years, we had better > check every year since 1970 ... What if we tell the user what the detected timezone is at some point, and tell them that it's only a heuristic? So if somebody gets a wrong timezone, they can select the correct one in postgresql.conf. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Tulio: oh, para qué servirá este boton, Juan Carlos? Policarpo: No, aléjense, no toquen la consola! Juan Carlos: Lo apretaré una y otra vez.
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote:
>> Perhaps, rather than just probing a few selected years, we had better
>> check every year since 1970 ...
> What if we tell the user what the detected timezone is at some point,
> and tell them that it's only a heuristic? So if somebody gets a wrong
> timezone, they can select the correct one in postgresql.conf.
That's the ultimate fallback in any case. But it would be nice if it
"just worked" in as many cases as possible. (Or should I revert the
hack that made it work for *your* timezone? ;-))
I was initially thinking that probing a large number of test times
would be expensive, but on second thought I don't see that it would
be a problem. On nearly all the entries in the TZ database, we'd
reject on the first or second probe time anyway; only very near
matches such as in Chris' example would need multiple checks. We
could probably check every Sunday from 1970-1-1 to current time
without making any visible difference in the speed of postmaster
launch ... and I think we might *have* to do that, if there are any
cases where similar zones differ only in the specific dates of
DST start/end.
regards, tom lane
I wrote:
> I was initially thinking that probing a large number of test times
> would be expensive, but on second thought I don't see that it would
> be a problem. On nearly all the entries in the TZ database, we'd
> reject on the first or second probe time anyway; only very near
> matches such as in Chris' example would need multiple checks.
I've committed changes that replace the original "spot check" approach
with consistently checking every week from 1970 to 2004. This is indeed
not much slower than before (the worst difference I saw was from 7 to 14
milliseconds required for identify_system_timezone to process the same
case, and I think some of that was measurement noise). This fixes Chris'
Australia/Perth problem at least.
It occurs to me that with a check this thorough, we might be able to
finesse the problem on Windows with the system returning very
nonstandard timezone abbreviations. That is, we might simply
"#ifndef WIN32" the matching of zone names in try_timezone().
However I do not know whether this would yield reasonable results for
all the zones supported by Windows. Does anyone want to try it?
regards, tom lane