Joachim Wieland [EMAIL PROTECTED] writes:
Getting a list of active timezones could be easily done
with a system view but you might not want to promise its existence when you
think about moving the whole thing to a system catalog later...
A read-only view wouldn't be a bad idea, actually, for
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
HADT -32400 D # Hawaii-Aleutain Daylight Time
# (America/Adak)
HAST -36000#
On Tue, Jun 13, 2006 at 02:20:09PM +0200, Joachim Wieland wrote:
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
sip
Any particular reason this can't be a
Joachim Wieland [EMAIL PROTECTED] 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
Martijn van Oosterhout kleptog@svana.org writes:
Any particular reason this can't be a normal table in pg_catalog which
you can select/update.
That doesn't do anything to help with one of the main problems: that
we have at least two (maybe more) alternative sets of names that people
might want
On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Any particular reason this can't be a normal table in pg_catalog which
you can select/update.
That doesn't do anything to help with one of the main problems: that
we have at least
On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote:
On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Any particular reason this can't be a normal table in pg_catalog which
you can select/update.
That
Martijn van Oosterhout kleptog@svana.org writes:
What I was thinking is why we couldn't just store the information in a
global shared system table that is only read on config reload. You
could have a few columns, maybe the first being a list name, which is
referenced from a GUC.
Hmmm ... if
Martijn,
On Fri, May 26, 2006 at 03:03:15PM +0200, Martijn van Oosterhout wrote:
I think you may be thinking of yet a separate TODO item, which is to
be able to use the zic timezone names in timestamptz input, viz
'2006-05-24 21:11 Americas/New_York'::timestamptz
But names like 'IST'
On Wed, May 24, 2006 at 09:13:42PM -0400, Tom Lane wrote:
The zic database doesn't seem to have a problem with using the same
abbreviations to mean many different things. We could look to it for
information, or maybe even use its classification of timezone groups,
but I don't think it can
I'd like to know what exactly is to be done for this TODO-item
o Allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
The most recent mail in the archives about this subject seems to be:
Joachim Wieland [EMAIL PROTECTED] writes:
I'd like to know what exactly is to be done for this TODO-item
o Allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
Well, part of the TODO is to figure out exactly what to do ;-)
So we'd need
12 matches
Mail list logo