- From: Michael Thornburgh <mthornbu@adobe.com>
- Date: Tue, 7 Mar 2017 22:53:40 +0000
- To: Joe Touch <touch@isi.edu>, Wesley Oliver <wesley.olis@gmail.com>, "nicolas.mailhot@laposte.net" <nicolas.mailhot@laposte.net>
- CC: Jim Reid <jim@rfc1035.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
the following table hopefully (if rendered in a monospace font) illustrates the problem with the unix timescale: elapsed "unix" UTC TAI 0 0 1970-01-01 00:00:0? 1970-01-01 00:00:10 * [...] 63072000 63072000 1972-01-01 00:00:00 1972-01-01 00:00:10 ** [...] 1483228824 1483228798 2016-12-31 23:59:58 2017-01-01 00:00:34 1483228825 1483228799 2016-12-31 23:59:59 2017-01-01 00:00:35 1483228826 1483228799 2016-12-31 23:59:60 2017-01-01 00:00:36 *** 1483228827 1483228800 2017-01-01 00:00:00 2017-01-01 00:00:37 1483228828 1483228801 2017-01-01 00:00:01 2017-01-01 00:00:38 1483228829 1483228802 2017-01-01 00:00:02 2017-01-01 00:00:39 * unix epoch, extrapolated from 63072000. ** start of the UTC leap second era *** latest leap second the main problem with the unix timescale is a conflation between timekeeping and time representation. the unix timescale is a time representation timescale (like UTC or TAI), but with a major deficiency: not all moments in time have a unique unix time representation. and the major bug is that people/software use this deficient time representation form for time*keeping* and naive interval measurement -- that is, they treat it as though it was "elapsed time" instead of a presentation form.
Received on Tuesday, 7 March 2017 22:54:15 UTC