Jim,
> Arguably, we could just create an add-on data type for storing that timezone information, but that seems pretty daft
tome: you're stuck either storing raw text which takes what should be a 12 byte datatype up to a 20-30 byte type (8
bytetimestamp + varlena + text of timezone name), or you end up with major problems trying to keep an enum in sync with
whatthe 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
