From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | "Dann Corbit" <DCorbit(at)connx(dot)com>, "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [pgsql-hackers-win32] Weird new time zone |
Date: | 2004-07-22 05:35:55 |
Message-ID: | 5649.1090474555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> Right. The problem we are actually faced with is to identify
>> which of the zic timezones is the best match for the system's
>> timezone setting.
>> One of the issues is that it's not clear what "best" means...
>>
>> At the moment I like Oliver Jowett's idea of defining "best"
>> as "the one that matches furthest back".
> Sounds reasonable to me. As long as a clear warning is put in the log
> whenever something is picked that is not a perfect match, so the admin
> is directed at the potential problem and can fix it (by setting the GUC
> timezone variable).
I'm not sure that a log entry is needed --- SHOW TIMEZONE will make it
perfectly clear what zone was selected.
But in any case, I've committed code that implements Oliver's idea.
Could folks take another swipe at it and see if it works well in their
local zones? Also, it'd still be interesting to see if we could #ifdef
out the matching on zone names for Windows and still get reasonable
results.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-07-22 06:54:06 | Fixing PKs and Uniques in tablespaces |
Previous Message | Gavin Sherry | 2004-07-22 05:23:47 | Completed TODO item? |