Thread: AT TIME ZONE with full timezones
This patch makes it possible to use the full set of timezones when doing "AT TIME ZONE", and not just the shorlist previously available. For example: SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London'; works fine now. It will also obey whatever DST rules were in effect at just that date, which the previous implementation did not. It also supports the AT TIME ZONE on the timetz datatype. The whole handling of DST is a bit bogus there, so I chose to make it use whatever DST rules are in effect at the time of executig the query. not sure if anybody is actuallyi *using* timetz though, it seems pretty unpredictable just because of this... Docs updates forthcoming assuming this approach is considered good ;-) //Magnus
Attachment
"Magnus Hagander" <mha@sollentuna.net> writes:
> This patch makes it possible to use the full set of timezones when doing
> "AT TIME ZONE", and not just the shorlist previously available.
> Docs updates forthcoming assuming this approach is considered good ;-)
Looks reasonable to me, please supply docs.
regards, tom lane
> > This patch makes it possible to use the full set of timezones when > > doing "AT TIME ZONE", and not just the shorlist previously > available. > > > Docs updates forthcoming assuming this approach is > considered good ;-) > > Looks reasonable to me, please supply docs. Great. Here is a doc patch. Turns out there were less mentions of this than I thought, so the patch is pretty small. //Magnus
Attachment
Patch applied. Thanks. Doc updates applied too. --------------------------------------------------------------------------- Magnus Hagander wrote: > This patch makes it possible to use the full set of timezones when doing > "AT TIME ZONE", and not just the shorlist previously available. For > example: > > SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London'; > > works fine now. It will also obey whatever DST rules were in effect at > just that date, which the previous implementation did not. > > It also supports the AT TIME ZONE on the timetz datatype. The whole > handling of DST is a bit bogus there, so I chose to make it use whatever > DST rules are in effect at the time of executig the query. not sure if > anybody is actuallyi *using* timetz though, it seems pretty > unpredictable just because of this... > > Docs updates forthcoming assuming this approach is considered good ;-) > > //Magnus Content-Description: timezones.patch [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings -- 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, Pennsylvania 19073