Actually, most software that needs to do time arithmetic accurately does not use UTC internally. Leap seconds make calculations for future times problematic using UTC. See http://en.wikipedia.org/wiki/Leap_second
Software in my field (space physics) uses epochs (seconds elapsed since an instant), or TAI. Conversion to "human friendly" dates/times such as UTC is done as the last step, and requires a leap second lookup table. Andrew J Davis (626) 429 0844 (cell) On Mar 8, 2013, at 11:48 PM, Jim Monty <jim.mo...@yahoo.com> wrote: > 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