Thread: How to store the time zone with a timestamp
I just realized that the type "timestamp with time zone" does NOT store
the time zone!
(And I just found this support list to look for help.)
I am developing an application that stores power (watts) readings from
meters
located around the world (abridged)--
power_meter_id integer NOT NULL,
"ts" timestamp with time zone NOT NULL,
power_reading real NOT NULL
Not storing the originating TZ is unacceptable. My search of this list
finds a number of
helpful discussions (including a reference to a TODO; soon I hope!) I
don't know
database programming and wonder if experienced users could reply with
some code
they've implemented.
I think the best solution is along Karsten's, which I believe goes like
this--
1) "ts" timestamp with time zone NOT NULL,
"tz" char( 6 ) NOT NULL, # '-12:00' to '+13:00'
2) A insert trigger that populates "tz"
3) Some function foo() that
a) calls timezone( tz, ts ) and
b) tacks on tz to the resulting string
in a "SELECT power_meter_id, foo( ts, tz ), power_reading;"
ANY snip its of code that implements anything related would be appreciated.
I can probably gin the complete solution seeing enough examples.
Thanks!
Andrew
BTW, if you wanted a more integrated solution, you could build a custom type that would store the timestamp info. There's a good chance such code would end up being what's used in the server as the official type, too. On Fri, Dec 16, 2005 at 08:57:04AM -0800, Andrew B. Young wrote: > I just realized that the type "timestamp with time zone" does NOT store > the time zone! > (And I just found this support list to look for help.) > > I am developing an application that stores power (watts) readings from > meters > located around the world (abridged)-- > power_meter_id integer NOT NULL, > "ts" timestamp with time zone NOT NULL, > power_reading real NOT NULL > > Not storing the originating TZ is unacceptable. My search of this list > finds a number of > helpful discussions (including a reference to a TODO; soon I hope!) I > don't know > database programming and wonder if experienced users could reply with > some code > they've implemented. > > I think the best solution is along Karsten's, which I believe goes like > this-- > 1) "ts" timestamp with time zone NOT NULL, > "tz" char( 6 ) NOT NULL, # '-12:00' to '+13:00' > 2) A insert trigger that populates "tz" > 3) Some function foo() that > a) calls timezone( tz, ts ) and > b) tacks on tz to the resulting string > in a "SELECT power_meter_id, foo( ts, tz ), power_reading;" > > ANY snip its of code that implements anything related would be appreciated. > I can probably gin the complete solution seeing enough examples. > > Thanks! > Andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Dec 16, 2005 at 03:18:04PM -0600, Jim C. Nasby wrote: > BTW, if you wanted a more integrated solution, you could build a custom > type that would store the timestamp info. There's a good chance such > code would end up being what's used in the server as the official type, > too. Well, I wrote a module for storing arbitrary tags with base types. One of the uses would be for a timestamp that remembers the timezone. I havn't received all that much feedback on it which leads me to conclude timestamps-remebering-timezones are not a heavily requested feature. It's probably on the same level as the ENUM suggested a while ago. Interesting, but not enough to get it included into core. http://svana.org/kleptog/pgsql/taggedtypes.html That said, I'd love for a variation of this to be included since I beleive it has a lot of applications not thought of yet. If user-types could define their own typmod values, that'd make it complete. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
On Fri, Dec 16, 2005 at 11:25:22PM +0100, Martijn van Oosterhout wrote: > On Fri, Dec 16, 2005 at 03:18:04PM -0600, Jim C. Nasby wrote: > > BTW, if you wanted a more integrated solution, you could build a custom > > type that would store the timestamp info. There's a good chance such > > code would end up being what's used in the server as the official type, > > too. > > Well, I wrote a module for storing arbitrary tags with base types. One > of the uses would be for a timestamp that remembers the timezone. I > havn't received all that much feedback on it which leads me to conclude > timestamps-remebering-timezones are not a heavily requested feature. > It's probably on the same level as the ENUM suggested a while ago. > Interesting, but not enough to get it included into core. > > http://svana.org/kleptog/pgsql/taggedtypes.html > > That said, I'd love for a variation of this to be included since I > beleive it has a lot of applications not thought of yet. If user-types > could define their own typmod values, that'd make it complete. Wow, that's damn cool and useful. You should put it on pgFoundry (at least as a project that links back to your site) so people can find it there. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
We have a TODO also:
o Allow TIMESTAMP WITH TIME ZONE to store the original timezone
information, either zone name or offset from UTC [timezone]
If the TIMESTAMP value is stored with a time zone name, interval
computations should adjust based on the time zone rules.
---------------------------------------------------------------------------
Jim C. Nasby wrote:
> BTW, if you wanted a more integrated solution, you could build a custom
> type that would store the timestamp info. There's a good chance such
> code would end up being what's used in the server as the official type,
> too.
>
> On Fri, Dec 16, 2005 at 08:57:04AM -0800, Andrew B. Young wrote:
> > I just realized that the type "timestamp with time zone" does NOT store
> > the time zone!
> > (And I just found this support list to look for help.)
> >
> > I am developing an application that stores power (watts) readings from
> > meters
> > located around the world (abridged)--
> > power_meter_id integer NOT NULL,
> > "ts" timestamp with time zone NOT NULL,
> > power_reading real NOT NULL
> >
> > Not storing the originating TZ is unacceptable. My search of this list
> > finds a number of
> > helpful discussions (including a reference to a TODO; soon I hope!) I
> > don't know
> > database programming and wonder if experienced users could reply with
> > some code
> > they've implemented.
> >
> > I think the best solution is along Karsten's, which I believe goes like
> > this--
> > 1) "ts" timestamp with time zone NOT NULL,
> > "tz" char( 6 ) NOT NULL, # '-12:00' to '+13:00'
> > 2) A insert trigger that populates "tz"
> > 3) Some function foo() that
> > a) calls timezone( tz, ts ) and
> > b) tacks on tz to the resulting string
> > in a "SELECT power_meter_id, foo( ts, tz ), power_reading;"
> >
> > ANY snip its of code that implements anything related would be appreciated.
> > I can probably gin the complete solution seeing enough examples.
> >
> > Thanks!
> > Andrew
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
>
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
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