Thread: AT TIME ZONE
With the new timezone stuff, is there any reason this shouldn't be made to work now in CVS: test=# select current_timestamp at time zone 'Australia/Perth'; ERROR: time zone "australia/perth" not recognized Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> With the new timezone stuff, is there any reason this shouldn't be made
> to work now in CVS:
> test=# select current_timestamp at time zone 'Australia/Perth';
> ERROR: time zone "australia/perth" not recognized
Lack of round tuits. We have to look at merging the hardwired zone
names in the datetime token table with the zic timezone names. And
somewhere in there the 'australian_timezones' GUC variable should vanish
in favor of a locally-configurable list of recognized TZ names. But
it's not happening for 8.0 ... this was stuff to be doing two months
ago ...
regards, tom lane
TODO entry? --------------------------------------------------------------------------- Tom Lane wrote: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > > With the new timezone stuff, is there any reason this shouldn't be made > > to work now in CVS: > > test=# select current_timestamp at time zone 'Australia/Perth'; > > ERROR: time zone "australia/perth" not recognized > > Lack of round tuits. We have to look at merging the hardwired zone > names in the datetime token table with the zic timezone names. And > somewhere in there the 'australian_timezones' GUC variable should vanish > in favor of a locally-configurable list of recognized TZ names. But > it's not happening for 8.0 ... this was stuff to be doing two months > ago ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> TODO entry?
* Merge hardwired timezone names with the TZ database; allow either kind everywhere a TZ name is currently taken
* allow customization of the known set of TZ names (generalize the present australian_timezones hack)
I'm not sure whether we already have an entry for the latter.
regards, tom lane
Folks, I wonder whether this TODO item also covers cases such as inserting into a table where one field is time in the local timezone and the other is time in GMT. Not sure if such a thing is desirable or even possible (in the SQL standard). The syntax I'm imagining feels pretty awkward. I guess the select syntax would allow storing gmt in both fields but extracting one as local and the other as gmt. Shahbaz On Tue, 24 Aug 2004 10:46:23 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > TODO entry? > > * Merge hardwired timezone names with the TZ database; allow either kind > everywhere a TZ name is currently taken > * allow customization of the known set of TZ names (generalize the > present australian_timezones hack) > > I'm not sure whether we already have an entry for the latter. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Shahbaz Javeed
On Tue, Aug 24, 2004 at 03:16:30PM -0400, Shahbaz Javeed wrote: People, > I wonder whether this TODO item also covers cases such as inserting > into a table where one field is time in the local timezone and the > other is time in GMT. Not sure if such a thing is desirable or even > possible (in the SQL standard). The syntax I'm imagining feels pretty > awkward. I wonder instead if it will be possible to store a timestamp without timezone in one field, and a timezone in another field. So I can get back a timestamp at the second-field timezone. I know this works for abbreviations, but this doesn't help me solve the problem at DST boundaries (abbreviations change at that point). -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "The ability to monopolize a planet is insignificant next to the power of the source"
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I wonder instead if it will be possible to store a timestamp without
> timezone in one field, and a timezone in another field. So I can get
> back a timestamp at the second-field timezone.
"f1 AT TIME ZONE f2" would be exactly the way to do that.
> I know this works for abbreviations, but this doesn't help me solve the
> problem at DST boundaries (abbreviations change at that point).
Right, what we are talking about here is extending AT TIME ZONE to
accept full zic-database zone names.
regards, tom lane
Added to TODO. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > TODO entry? > > * Merge hardwired timezone names with the TZ database; allow either kind > everywhere a TZ name is currently taken > * allow customization of the known set of TZ names (generalize the > present australian_timezones hack) > > I'm not sure whether we already have an entry for the latter. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073