Bill Moseley wrote: > UTC is a timezone, too. UTC is only ever a "time zone" in implementations of computer models of time and timekeeping such as Perl DateTime. In fact, UTC is, by definition, NOT a time zone. It's the baseline reference time from which time in zones are reckoned. A time expressed in UTC records a moment in time (an "instant" in ISO 8601 parlance) without regard to geography or geopolitical boundaries. It's the time everywhere and nowhere. Zulu time.
A time expressed in UTC is absolute and universal. I think this is the point Karen was emphasizing: don't record times in a computer database in local time (in time zones) because these expressions of time are rule-based and have too many anomalies in them, which UTC representations of time do not have: a missing hour in some days, a repeated hour in other days, etc. > In our database we use "timestamp with time zone" and it doesn't matter > what timezone the database session uses as long as we use the timezone > when parsing the column data. For me, it helps to think of the time zone as an attribute of a person who needs to know what time it is, either now or when some even occurs. The time zone is not an attribute of a moment in time. Time zones are more about location than they are about time. So imagine if you abandoned all efforts to record instants in local time and instead always recorded them in the single, universal reference time, UTC. Perform all date and time arithmetic using these moments uniformly recorded in UTC. Instead of storing the time zones along with each moment in time, store the time zones of the people who need to have the times expressed to them in their personal local time. This is what Microsoft Office Outlook does. I suspect it's how most modern computer software handles timestamps. Jim Monty
