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

Reply via email to