Thread: Time zone definitions to config files
Here's the patch that generalizes the australian_timezones hack by moving the
compiled-in time zone definitions into a text file. The text file to use is
chosen via a guc.
The patch comes with `template' files and `set' files. The template files
contain all time zones that I could find, i.e. are autogenerated from zic and
later I added other time zones manually like those from the old pgsql source.
The set files are what you can then specify in the configuration. The default
set is called `Default' and should work for like 90% of the world. A guc
parameter called `timezone_abbreviations' specifies which set to load.
Similar
to setting `australian_timezones = true' today, an Australian would set
`timezone_abbreviations = Australia' and the set called `Australia' gets
loaded. Basically this file includes the default set and overrides the time
zone information from there with the conflicting Australian time zones. This
include/override feature makes it possible to keep the local sets really
small
and to ship almost everything in the default set. There is another set,
`India', that also includes the default set but then defines the `IST' time
zone differently (is defined to Israel time by default).
Sets get installed to share/timezone/tznames/sets/ and templates to
share/timezone/tznames/templates.
Anybody can think of better names?
From a functionality point of view the template files are not necessary, they
just serve as a template to copy and paste from for someone who is missing
time zone definitions. Also you can see which time zone names do collide. I'd
vote for including them anyway into the distribution but other people might
think differently.
The set gets re-read after server start and SIGHUP. If an error occurs during
server start, the start fails. If the error occurs while reading the
definitions after SIGHUP, a warning message is issued and no changes get
applied.
The default set also changes, adds and removes a few time zones:
Changes to time zone entries:
BDST (British Double Summer Time) was not marked as DST, is now
AKST (Alaska Standard Time) was marked as DST, but is no longer
ALMST (Almaty Savings Time) was not marked as DST, is now
FKT (Falkland Islands Time) was -2 hours and is -4 now
GEST/GET (Georgia (Summer) Time) was +5/+4 and is +4/+3 now
(there was a time zone change in 2004 (-> zic))
IOT (British Indian Ocean Territory (Chagos)) was +5 and is +6 now
(there was a time zone change in 1996 (-> zic))
KOST (Kosrae Time) was +12 and is now +11
(there was a time zone change in 1999 (-> see zic))
KRAST/KRAT (Krasnoyarsk (Summer) Time) was +7/+8 and now got corrected to
+8/+7
RET (Reunion Island Time) was marked as DST, but is no longer
SCT (Mahe Island Time) was marked as DST, but is no longer
WAT (West Africa Time) was -1, but is +1 actually
New time zones:
PMST added for consistency, PMDT was already there
UCT - Universal Coordinated Time
Time zones names that get removed:
"(init)" means that the time zone existed already in dt.h and is like 7 years
old. The rationale to be more reluctant to remove other entries is that there
might have been a reason for why they got added.
AHST - Alaska/Hawaii Standard Time (init)
http://www.worldtimezone.com/wtz-names/wtz-ahst.html (1967-1983)
AWT - (unknown)
BT - Baghdad Time (init)
CAT - Central Alaska Time
http://www.worldtimezone.com/wtz-names/wtz-cat.html (until 1967)
CVT - Christmas Islands Time (is CXT actually)
found references to Cape Verde Time but with different offset (-)
DNT - Dansk Normal Tid (init)
FST - French Summer Time (init)
FWT - French Winter Time (init)
GST - Guam Standard Time, Russia zone 9 (init)
HDT - Hawaii/Alaska Daylight-Saving Time (init)
http://www.worldtimezone.com/wtz-names/wtz-hdt.html (until 1947)
HMT - Hellas Mediterranean Time (?) (init)
IDLE - International Date Line, East (init)
IDLW - International Date Line, West (init)
IT - Iran Time (init)
JST - Japan Standard Time, Russia zone 8 (init)
JT - Java Time (init)
METDST - Middle Europe Daylight-Saving Time (init)
MEWT - Middle European Winter Time (init)
MT - Moluccas Time (init)
NOR - Norway Standard Time (init)
NT - Nome Time (init)
SST - Swedish Summer Time (init)
SWT - Swedish Winter Time (init)
THAT - found more references for TAHT
TRUK - found more references for TRUT
SET - Seychelles Time (init)
YDT - Yukon Daylight-Saving Time (init)
YST - Yukon Standard Time (init)
ZP4 - (init)
ZP5 - (init)
ZP6 - (init)
Does anybody vote against removing one of those time zones?
The patch also adds a system view pg_timezonenames that contains name, offset
and a boolean flag to indicate whether or not this is a daylight saving time
zone.
Review and comments welcome,
Joachim
(sorry if this mail contains stupid line wrapping, I only have webmail
access right now)
Attachment
"Joachim Wieland" <joe@mcknight.de> writes:
> Here's the patch that generalizes the australian_timezones hack by moving the
> compiled-in time zone definitions into a text file. The text file to use is
> chosen via a guc.
Applied with some revisions --- mostly, that I didn't like restricting
timezone_abbreviations to be changed only via postgresql.conf. The old
australian_timezones setting was always USERSET, and I think people
would have had a legitimate gripe about loss of flexibility if its
replacement wasn't. Fortunately this wasn't too hard to change. I also
editorialized a bit on the file placement and the parsing code.
The documentation is still in need of help ... in particular, Table B-4
(timezone names) is now out of sync with reality. I am not sure whether
to try to fix it, or just remove it and tell people to look at the
pg_timezonenames view. Thoughts? If you want to fix it, please send
a patch.
regards, tom lane
On Mon, Jul 24, 2006 at 11:59:34PM -0400, Tom Lane wrote: > "Joachim Wieland" <joe@mcknight.de> writes: > > Here's the patch that generalizes the australian_timezones hack by > > moving the compiled-in time zone definitions into a text file. The > > text file to use is chosen via a guc. > > Applied with some revisions --- mostly, that I didn't like > restricting timezone_abbreviations to be changed only via > postgresql.conf. The old australian_timezones setting was always > USERSET, and I think people would have had a legitimate gripe about > loss of flexibility if its replacement wasn't. Fortunately this > wasn't too hard to change. I also editorialized a bit on the file > placement and the parsing code. > > The documentation is still in need of help ... in particular, Table > B-4 (timezone names) is now out of sync with reality. I am not sure > whether to try to fix it, or just remove it and tell people to look > at the pg_timezonenames view. Thoughts? If you want to fix it, > please send a patch. I'll take a whack at that patch this evening PDT or tomorrow evening at the latest. We're too late in the cycle to go over this, but maybe we can figure out a way to have this data read from the same data source as the pg_timezones VIEW does at compile time. Keeping two such table in synch seems error-prone. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
David Fetter <david@fetter.org> writes:
> On Mon, Jul 24, 2006 at 11:59:34PM -0400, Tom Lane wrote:
>> The documentation is still in need of help ... in particular, Table
>> B-4 (timezone names) is now out of sync with reality.
> I'll take a whack at that patch this evening PDT or tomorrow evening
> at the latest. We're too late in the cycle to go over this, but maybe
> we can figure out a way to have this data read from the same data
> source as the pg_timezones VIEW does at compile time. Keeping two
> such table in synch seems error-prone.
Well, the problem is exactly that there is no "same data source"
anymore: the local DBA can customize the timezone list all he wants.
We could document what the out-of-the-box settings are, but is it
really useful to duplicate that info in the SGML docs? We don't
for example provide a copy of psql \df+ output in the SGML docs,
and I'm wondering if this isn't kind of the same animal.
regards, tom lane
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > I'll take a whack at that patch this evening PDT or tomorrow evening > > at the latest. We're too late in the cycle to go over this, but maybe > > we can figure out a way to have this data read from the same data > > source as the pg_timezones VIEW does at compile time. Keeping two > > such table in synch seems error-prone. > Well, the problem is exactly that there is no "same data source" > anymore: the local DBA can customize the timezone list all he wants. > We could document what the out-of-the-box settings are, but is it > really useful to duplicate that info in the SGML docs? We don't > for example provide a copy of psql \df+ output in the SGML docs, > and I'm wondering if this isn't kind of the same animal. I'd vote for not including it. The current table is way out of sync already. I first chose the timezones for the "Default"-set based on this table in the docs but then I noticed that the table does not really reflect the timezones in the source code. With the view it's now almost trivial to keep both synced but it still is a source of errors. Furthermore since nobody has complained about the incorrect table so far, I don't think many people care. And those who do can easily consult the view or the file of the Default set directly. Joachim