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

Hi, Michael,

Yes, thanks of for the clarification and catching some errors - notes below.

Joe

On 3/7/2017 11:40 AM, Michael Thornburgh wrote:
>> From: Joe Touch [touch@isi.edu]
>> Sent: Tuesday, March 7, 2017 8:33 AM
>> [...]
>> A summary of details:
> this isn't quite right.
>
>> 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).
> i think you're thinking of "TAI" ("International Atomic Time"), not "TA" or "TA1".

Yes. Darned tiny screen - I thought the "I" was "1". I should have
remembered TAI.

>   TAI is a consensus timescale based on numerous atomic clocks around the world (to correct for relativistic/gravitational time dilation).  it theoretically ticks at one SI second per TAI second.  the TAI timescale has exactly 86400 SI seconds per day every day, no matter what.
>
> UT1 is still a thing.  it is based on the rotation of the earth as measured with respect to distant celestial objects.  the UT1 timescale divides each day into 86400 segments called "seconds", which may be shorter or longer than SI seconds depending on how fast the earth is rotating that day.  UT1 is the same everywhere on the earth all the time, but UT1 seconds aren't SI seconds, which is annoying.
>
> because TAI ticks at one SI second and UT1 ticks at 1/86400 earth rotation, TAI and UT1 are divergent.

UT actually has several variants, all of which are intended to sync to
the Earth's rotation. UT0 is star based, and isn't used much. UT1 is
mean solar time (a daily mean), UT1R smooths UT1 to reduce the effect of
tides (like a monthly mean), and UT2 smooths out seasonal variations in
UT1R (like a yearly mean). UTC is TAI with leapseconds, intended to
approximate UT1. They all diverge from TAI because TAI is a physical
constant (at least within the same gravitational frame of reference),
and UT is tied to Earth rotation.

TAI is probably the one you want for relative timekeeping; that's the
one that gets converted to UTC.

> 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.
> "UTC" ("Coordinated Universal Time") is a timescale that (as of about 1972) ticks at the same rate and at the same time as TAI.  UTC is occasionally tweaked with leap seconds (either adding or subtracting a second from the timescale) to keep UTC within 0.9 seconds of UT1.  the last leap second's name in the timescale was "2016-12-31 23:59:60 UTC".  UTC is currently behind TAI by 37 seconds.
>
>> 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.
> the Unix timescale is the number of seconds, *not including leap seconds*, since 1970-01-01 00:00:00 UTC, while *also* being synchronized to UTC assuming each day has exactly 86400 seconds.  this is the most broken possible way of dealing with the time.  the positive leap seconds are not representable in this timescale, and all kinds of horrible hacks (like repeating the last second before a positive leap second, or time smearing) are done to compensate.
Agreed - it approximates UT, but without the leapseconds it's just
always wrong.

> the Unix timescale *should* be "the number of SI seconds elapsed since 1970-01-01 00:00:00 UTC", 

I.e., TAI relative to the Unix epoch... except that it starts with an
epoch of 1977-01-01

> and all of the library routines for converting between Unix time and the civil/human timescales (UTC, TAI, local times) should take leap seconds into account as appropriate.

TAI isn't civil or human; it's scientific (physical).

UT (and its variants) are civil/human, as are local times.

Joe

Received on Tuesday, 7 March 2017 20:01:16 UTC