[LEAPSECS] Time math libraries, UTC to TAI

[John Sauter]

On Mon, 2016-12-26 at 08:43 -0500, Brooks Harris wrote:
...
> 
> I wonder if the computer industry might not have long since adopted a
> more accurate UTC-based local time timekeeping system if a
> specification for one actually existed. But it doesn't, and that, it
> seems to me, should be the objective; to develop a suite of
> specifications that consolidates the UTC specs, codifies the meaning
> and representation of local time, and specifies reverse compatible
> mapping to existing systems. This needs to be accompanied by format
> and protocol specifications together with reference implementations.
> Without a plan its hard to imagine how convergence on a uniform
> timekeeping system comes about.
> 
> The existing systems are not going to be replaced; they all need to
> be supported while defining a more uniform and UTC-accurate set of
> procedures that may be used in parallel with, beside, on top of, or
> in conjunction with, existing systems. If we keep arguing about what
> UTC and POSIX are or are not because we don't like one or the other I
> don't see how we get very far.
> 
> -Brooks

I'm not a great fan of standards, myself.  I once quipped that "The
purpose of standards is to make the future repeat the mistakes of the
past, rather than invent their own."  However, if you think it is
important to have standards for local timekeeping based on UTC, then I
urge you to begin work on them.  UTC itself already has a formal
document describing it: TF460-6 at <https://www.itu.int/dms_pubrec/itu-
r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf>.  The representation of
local time has a standard: ISO 8601, though people pretty much use RFC
3339 instead.  POSIX has time_t (bletch) and the tm structure.

Standards for local time based on UTC should reflect what people are
actually doing.  If what people are doing is wrong, then I feel we
should correct current practices first, and then write the standard.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20161226/f2796fcc/attachment.pgp>