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

> From: Joe Touch []
> 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".  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.

> 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.

the Unix timescale *should* be "the number of SI seconds elapsed since 1970-01-01 00:00:00 UTC", 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.

Received on Tuesday, 7 March 2017 19:41:22 UTC