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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to