Richard Troy <rtroy@ScienceTools.com> writes:
> I'm not fully caught up with my Readings In Postgres, but this post caught
> my eye and raised a concern...
AFAIK, all the reasons you enumerate are good reasons to delegate the
problem to a timestamp WITH time zone column.
> First, you need at least minute, if not second offset from GMT to have
> anything like a comprehensive shot at "timezone."
Got that.
> The second biggest issue is probably the plethora of "daylight savings
> time" schemes - and they change over time:
Got that, if you keep your zic data files up to date.
> Third, any presumption about when which version of a time should be valid
> is bound to cause major errors at some point or another.
No doubt, but doing conversions outside the database is surely no safer
than doing them inside.
> We at Science Tools use "timestamp without timezone" as the basis of our
> handling our customer's data correctly. It's configurable, but by default
> all data going into a database is converted to GMT by our software,
> outside the database engine, unless explicitly directed otherwise.
I think you're just reinventing timestamp with time zone. Maybe if you
need to work with other DBs besides Postgres, you'll have to program to
the lowest common denominator, but PG gets all these things right.
regards, tom lane