Am Donnerstag, 11. Oktober 2007 schrieb Gregory Stark:
> Thinking of it as UTC is the wrong way to think about it. A birth occurred
> at a specific moment in time. You want to record that precise moment, not
> what it happened to show on the clock at the time. If the clock turns out
> to have been in the wrong timezone the birth isn't going to move.
>
> The use case for storing a local timestamp with a timezone attached is for
> things like appointments. If the time zone rules change you would want the
> appointment to move with them, not to stay at the same moment in time.
The difference here is that one occured in the past and one is planned for the
future. Appointments in the past will still stay at the same time even if
the time zone rules change afterwards.
The supercorrect way to handle this would likely be to introduce some sort of
time-zone rules changeset that describes "as of point in time X, the time
zone designation ABC changes in the following way", which would then fix up
all data items past point X in the database in some clever way. Obviously
this is quite a bit too much for us to manage.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
