Re: timezones to own config file

Joachim Wieland <joe(at)mcknight(dot)de> writes:
> The timezone definition files should be read at server start but should they
> also be read at SIGHUP? If so, should they be read only by the postmaster or
> by all backends?

Presumably the name of the definition file to use will be a GUC
variable. I would expect the code to re-read the file any time the
variable's value is changed. In the case of a change via postgresql.conf
this would automatically happen in all backends as well as the
postmaster. You'll need to make it follow the semantics already in use
for errors in postgresql.conf, viz:
* error detected during postmaster startup -> report error and quit
* error detected during postmaster reload -> log message, ignore new setting
* error detected during backend reload -> debug message, ignore new setting

As far as the appropriate contents of the files go, I'd suggest *not*
trying to account for every abbreviation mentioned in the zic database;
lots of them are surely uninteresting, and anyone who does want Nome Time
will now be able to add it for himself. The more abbreviations you try
to understand, the less chance you have of detecting plain old errors.

IIRC, the conflicts we've actually heard about in practice are IST
(Israel vs India) and Aussie vs. USA zone names. So it might work to
have two base definition files, one for Europe/Americas (with USA and
Israel names) and one for Far East (with Aussie and Indian names).

I am not sure where Tom Lockhart got the list of timezone names that's
currently hardwired in datetime.c, but for sure you needn't treat it as
being graven on stone tablets.

regards, tom lane