Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

> On Mar 7, 2017, at 7:06 AM, wrote:
> De: "Joe Touch" 
>> UTC requires a table to compute deltas if any period spans a leap second. UT avoids that's issue if your
>> optimizing for computing deltas.
> Sure, but not enough software cares about the leap second for UT support to be widespread. UTC is the only realistic option if one wants to use of-the-shelf components.

There are trade-offs, certainly. The issue isn't just what format you can implement; it's what format you use as your *primary* encoding, e.g., when storing time stamps in a large database. Pick the wrong one and you spend a lot of cycles converting. No single format avoids conversions for three common uses:

	- to compute deltas or establish strict ordering (UT, now called TA)
	- to interact with official government times (UTC is the standard)
	- to present information to a human user conveniently (people want localtime)

A summary of details:

UT (now called TA, FYI):	native for deltas and ordering; requires leapsecond table to convert to UTC, also requires location and zone/savings table to convert to local time. There are variants of this; the most common  is TA1 (prev. known as UT1).

UTC: most widely supported, requires a leapsecond table to compute deltas, requires location and zone/savings table to convert to local time. UTC is defined as TA1 adjusted for leapseconds.

Local time: typically preferred display for people, requires location and zone/savings table to calculate deltas or convert to UTC. Local time is defined as UTC adjusted for time zone location and daylight savings.

So, optimizing for deltas you would want to use UT as your primary format. Optimizing for interoperation with existing protocols/devices you would use UTC as your primary format. Optimizing for interaction with users you would use local time as your primary format.

And the list above explains what other information you would need if you want to also support formats other than the primary encoding used.

Unix time is (IMO) a poor approximation of UT (or TA), at best.


Received on Tuesday, 7 March 2017 16:35:22 UTC