Re: Timezone database changes

On 10/11/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Trevor Talbot" <quension(at)gmail(dot)com> writes:

> > While I agree that UTC storage is definitely a needed option, I was
> > trying to point out in the scenario above that sometimes an event
> > recorded at a specific moment in time *is* local time. Birth
> > certificates aren't in UTC. Usually there's no practical difference,
> > but there can be a semantic difference.
>
> 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.

Neither is the birth certificate. The recorded, legal time of the
birth is the one that was written down. If it doesn't happen to match
an international notion of current time, that's unfortunate, but it's
not subject to arbitrary changes later. Even if it does match, it
still belongs to a specific time zone. That's the key semantic point:
regurgitating that time as anything other than exactly what it was
entered as is simply not correct.

Birth dates enter common usage with the time zone stripped. Your
birthday doesn't change when you move across a date line, despite the
fact that it's tied to the zone you were born in.

And yet it's an observed and recorded event, not a predicted appointment.