- From: Michael Sweet <msweet@apple.com>
- Date: Sun, 19 Mar 2017 08:49:23 -0400
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: Joe Touch <touch@isi.edu>, nicolas.mailhot@laposte.net, Wesley Oliver <wesley.olis@gmail.com>, Jim Reid <jim@rfc1035.com>, ietf-http-wg@w3.org
Amos, > On Mar 18, 2017, at 9:23 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: >> ... >> - 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. Um, I don't think any conformance terminology can be applied to people... And since this is a BCP document, I'm not sure capitalized conformance terminology even makes sense for this document as a whole. Better to word this non-normatively but otherwise strongly - make a declarative statement, e.g., "time scales are defined by experts so that system designers can choose an appropriate one", and then provide guidance on how to choose the appropriate time scale. > >> 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 _________________________________________________________ Michael Sweet, Senior Printing System Engineer
Received on Sunday, 19 March 2017 12:50:04 UTC