Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

Tony Finch <> Tue, 27 November 2018 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CCCD130DE3 for <>; Tue, 27 Nov 2018 08:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xbatFf68omqv for <>; Tue, 27 Nov 2018 08:46:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37AD4130DDA for <>; Tue, 27 Nov 2018 08:46:10 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:58362) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gRgUy-0009w0-2u (Exim 4.91) (return-path <>); Tue, 27 Nov 2018 16:46:08 +0000
Date: Tue, 27 Nov 2018 16:46:08 +0000
From: Tony Finch <>
To: Brian Dickson <>
cc: " WG" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Nov 2018 16:46:13 -0000

[ trim CC: list due to off-topic tangent ]

Brian Dickson <> wrote:
> Doesn't UTC actually derive its time from TAI plus/minus leap seconds?

It's more complicated than that :-)

Strictly speaking, TAI is a paper clock, which is published as
retrospective corrections to national time lab reference clocks. In
practice what the general public has access to are time signals that trace
back to national versions of UTC, because those are the continuously
maintained reference timescales. GNSS time signals are an exception
because they mostly lack leap seconds, so their offset from TAI is fixed
to within some precision. But GPS time is only roughly TAI-19s.

> Why isn't it already available to use as a time zone?

Timezones on Unix have to be defined wrt POSIX time (because that's how
localtime() works), and POSIX time is a lossy representation of UTC, so
you can't get TAI that way without lossage. There were some experiments
defining TZ based on a TAI-ish non-standard time_t (the "right" aka wrong
timezones) but they aren't usable on a POSIX system. (But note the epoch
for the "right" timezones is 10s different from the SMPTE PTP epoch.

f.anthony.n.finch  <>
Fisher, German Bight: Southeasterly 5 to 7, increasing gale 8 later. Slight or
moderate, becoming rough or very rough later. Showers, rain later. Moderate or