- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 19 Mar 2017 14:23:25 +1300
- To: Joe Touch <touch@isi.edu>, nicolas.mailhot@laposte.net
- Cc: Wesley Oliver <wesley.olis@gmail.com>, Jim Reid <jim@rfc1035.com>, ietf-http-wg@w3.org
On 19/03/2017 4:01 a.m., Joe Touch wrote: > Hi, Nicolas, > > I agree that the advice is buried and maybe a little less direct than > would be useful. > > This issue began twice on the IETF list from suggestions that "we could > do better", especially in avoiding discontinuities or nonuniformity. The > point of this doc is that there's no short-cut. > > So here's a summary of what I think should be up front (with a few > paragraphs). Can you let me know if that's what you were expecting? > > Joe > > ------ > > - system designers SHOULD NOT invent their own time scale because every Heck no. Make that a MUST NOT. Place the invention of more time scales into the realm of standards design experts who hopefully actually understand all the implications and whether any exceptional case is already a solved problem. > gain that might be considered will be offset by significant pain when > coordinating with others later > - there are no shortcuts for dates compared across different systems - > maintaining those dates requires monitoring external info (leap seconds > and time zones), thus: > - dates SHOULD use UTC in most cases because it is the basis of all > civil time > - in general, a date system SHOULD maintain related information > about leap-seconds and time zones > - a date system that requires accurate interval calculation > MUST maintain that information > - applications that interact with users SHOULD record the location > of a date (e.g., as a time zone) > - dates MAY use TAI for applications that need to optimize for > interval calculations > - dates MAY use local time (UTC offset by the local time zone) for > applications that need to optimize for interacting with users > ... also IMHO have any mention of other weirdnesses later in the document be to deprecate them formally and require conversion to one of the above for any upgraded or new system. Same sort of process as done with broken crypto components. Amos
Received on Sunday, 19 March 2017 01:24:15 UTC