Re: [art] Fwd: New Version Notification for draft-touch-time-05.txt
Tony Finch <dot@dotat.at> Fri, 13 September 2019 19:41 UTC
Return-Path: <dot@dotat.at>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08C1120105 for <art@ietfa.amsl.com>; Fri, 13 Sep 2019 12:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4N3LL4t8E4i for <art@ietfa.amsl.com>; Fri, 13 Sep 2019 12:41:29 -0700 (PDT)
Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1592120116 for <art@ietf.org>; Fri, 13 Sep 2019 12:41:29 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60352) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1i8rRf-000DQ1-nM (Exim 4.92.2) (return-path <dot@dotat.at>); Fri, 13 Sep 2019 20:41:27 +0100
Date: Fri, 13 Sep 2019 20:41:26 +0100
From: Tony Finch <dot@dotat.at>
To: Joe Touch <touch@strayalpha.com>
cc: "art@ietf.org" <art@ietf.org>
In-Reply-To: <45c2fb64-1efd-68bf-4436-ec7bbb7bfc88@strayalpha.com>
Message-ID: <alpine.DEB.2.20.1909131844350.5352@grey.csi.cam.ac.uk>
References: <156834269242.16573.17240497030993366068.idtracker@ietfa.amsl.com> <45c2fb64-1efd-68bf-4436-ec7bbb7bfc88@strayalpha.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/MySoCcLSA6AqM1_4FS6Bv7tYwkA>
Subject: Re: [art] Fwd: New Version Notification for draft-touch-time-05.txt
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 19:41:33 -0000
I have read through the draft and I have a pile of pedantic comments... In the introduction you say, Many time frames contain discontinuities, some of which are regular (e.g., time zones, leap days, and daylight saving time shifts), whereas others are irregularly introduced as needed (e.g., leap seconds). I think it's less misleading to say that daylight saving time shifts are only regular for a limited number of years, and it should be mentioned that changes to DST rules occur at irregular and unpredictable times. Elaborating on your intro point 3, a rule of thumb I use for deciding when not to use UTC is if I need to work with times in the future that interact with people, in which case time needs to be described in local time in a particular place. The most common example is calendaring, but it can also occur for things like cron jobs that need to fit around office hours. In section 4: standard for the passage of time. Civil time is based on the rotation of the earth, and its goal is to ensure that a single geographic location has the same reference to the sun at the same time each day, including variations that support localized time to approximate that effect for other locations around the earth. I think "same reference to the sun" needs to be clarified, or perhaps needs to gloss over the details more. The difference between mean solar time and apparent solar time can be over 15 minutes (equation of time), and DST can add another hour, so the sun is basically not in the same place at the same time on different days. sun. Computational time can be non-uniform, such as when Unix system clocks are sped up to synchronize with civil time in a way intended to avoid discontinuity. If this is referring to leap smear, then that's a slowdown. o Ordering: to determine the relative sequence of events across systems, such as with Lamport clocks [La78] or Vector clocks [Fi88][Ma88]. Lamport clocks and vector clocks don't use time, but the section heading implies that they do. o Interacting with people: to exchange dates with the real world, as when indicating the civil date of an email transmission [RFC3339], web page [ISO98], or managing calendars [RFC5545]. Email date staps are specified in RFC 5321 and RFC 5322 and are not the same format as RFC 3339. The HTTP date header is specified in RFC 7231 not ISO 8601. I'm not sure what the 98 in the ISO anchor refers to (the current edition is dated 2019, this year). o NTP [RFC5905]: the Network Time Protocol, used in the Internet to synchronize local clocks, in which dates are indicated by UTC values. NTP times track the time of the clock they connect to. NTP uses a unix-style count of seconds so it isn't able to represent UTC values. The NTP leap indicator bits are not synchronized with the occurrence of leap seconds so they don't disambiguate leapy timestamps. https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues 4.3. Comparison of properties Should the discussion of GLONASS etc. be moved to section 5 before the table in which they occur? Should PTP be added to the list of time scales? (Given section 7 talks about selecting timescales I think it's worth pointing out one that is of practical use in computing, as opposed to TAI which is a retrospective paper clock.) Unix time does not specify the definition of a 'second' or 'day', and so it is not clear whether it intends to track SI seconds (where time would be uniform) or solar time (where it would not). Unix time is defined in terms of struct tm fields, which are a representation of a UTC time stamp. It explicitly says it doesn't specify any relationship to real civil time. 6.1.3. Not uniform Some time scales replace discrete leap seconds with a leap smear, stretching the interval of one second over 10-20 hours before the corresponding leap second date [Go17]. I think the most common smearing approach in recent years is to centre the smear equally before and after the leap second, so the greatest difference from unsmeared time is 0.5s rather than 1s. https://pairlist6.pair.net/pipermail/leapsecs/2016-September/006308.html Google deployed leap smear in 2011 (not 2017 as your reference states) and they weren't the first to propose it. https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ 6.1.4. Ordering I think the leap smear example needs a caveat. Most implementations do the smear over several hours, not 2 seconds. Section 6 could do with a subsection about the dangers of calculating with future times, e.g. DUT1 is not known after a few months in the future, time zones and DST rules change several times a year, etc. 7.1. Selecting a time scale If user presentation is primary, as for email or calendaring, implementers would probably select local time [RFC5545]. More practically, calendaring systems need to support a comprehensive database of local times, and they can't pick a single one as primary because that's a recipe for timestamps in secondary timescales becoming wrong when tz rules change. 7.2. Hazards of some time scales It's worth mentioning that if you aspire to representing UTC correctly then it cannot be done as a simple count of seconds, and Unix and NTP are shining examples of getting it wrong. There should be a discussion of leap-second-related hazards in Unix time and NTP. The draft seems to give the impression that leap smear is a Google peculiarity, but there are several other organizations doing it (see the link to the leapsecs list above). That's probably enough nerdery for now... Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ individual and social justice
- [art] Fwd: New Version Notification for draft-tou… Joe Touch
- Re: [art] New Version Notification for draft-touc… Joe Touch
- Re: [art] Fwd: New Version Notification for draft… Tony Finch
- Re: [art] Fwd: New Version Notification for draft… Joe Touch
- Re: [art] Fwd: New Version Notification for draft… Joe Touch
- Re: [art] Fwd: New Version Notification for draft… Tony Finch
- Re: [art] Fwd: New Version Notification for draft… Joe Touch
- Re: [art] New Version Notification for draft-touc… Joe Touch
- Re: [art] New Version Notification for draft-touc… Steve Allen
- Re: [art] New Version Notification for draft-touc… Tony Finch
- Re: [art] Fwd: New Version Notification for draft… Tony Finch
- Re: [art] New Version Notification for draft-touc… Joe Touch
- Re: [art] New Version Notification for draft-touc… Joe Touch