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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
