Re: storing TZ along timestamps

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, "alvherre(at)alvh(dot)no-ip(dot)org Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: storing TZ along timestamps
Date: 2011-07-22 21:54:42
Message-ID: 4E29F1A2.9080705@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim,

> Arguably, we could just create an add-on data type for storing that timezone information, but that seems pretty daft to me: you're stuck either storing raw text which takes what should be a 12 byte datatype up to a 20-30 byte type (8 byte timestamp + varlena + text of timezone name), or you end up with major problems trying to keep an enum in sync with what the database has available in it's ZIC database.

Sure, although there's no getting around the portability issues. The
moment you move that data between servers, you risk having specific
timezones not be available on the second server. Or worse, be available
but have a different definition -- if, for example, you're running a
more/less updated PostgreSQL on the second server.

I'm not saying that this isn't worth solving. I could really use a
timezone datatype which was synched with ZIC in some way, and so could a
lot of other users, whether or not a timestamp + original timezone type
is available as well. But don't underestimate the scope of the problem.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joey Adams 2011-07-22 22:04:49 Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Previous Message Kevin Grittner 2011-07-22 21:51:49 Re: WIP fix proposal for bug #6123