Re: [RFC 0/2] ABI for clock_gettime_ns

From: Richard Cochran
Date: Thu Dec 15 2011 - 06:36:13 EST


On Wed, Dec 14, 2011 at 01:34:50PM -0800, john stultz wrote:

> FYI: Interesting additional emails from Steve Allen below (forwarded
> with permission) that put some caution around CLOCK_TAI.

I saw that, too, and I have a comment, below.

> -------- Forwarded Message --------
> From: Steve Allen <sla@xxxxxxxxxxx>
> To: John Stultz <johnstul@xxxxxxxxxx>
> Subject: TAI in linux kernel
> Date: Wed, 14 Dec 2011 11:44:23 -0800
>
> Greetings John Stultz,
>
> I note the linux kernel discussion mentioning the use of TAI.
>
> It may be relevant to note the position of the CCTF and BIPM on
> the use of TAI as expressed in Document CCTF/09-27
>
> http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf
>
> Their position is that they do not want TAI used as an operational
> system time, and in their last paragraph they make it plain that
> they would consider suppressing TAI in order to accomplish that.
>
> Building TAI into the linux kernel could result in the use of
> an nonexistent time standard.

Yes, they would do this only if UTC becomes continuous and decoupled
from the whole leap second mess. I don't think it would be a problem
for the kernel, since we could simply re-name the kernel time scale to
UTC+X, or just remove the offset and call it UTC.

This would only happen if and when everyone agrees to the UTC
redefinition. I am not holding my breath. Earlier on in the article we
read that "after serveral years of discussions and analysis of
documents no firm postion has been taken." That article is dated
2007. Is the UTC fixup any closer now than it was back then?

Also, TAI has already been standardized as an operational time scale
by IEEE standard 1588.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/