Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding


> On Mar 18, 2017, at 9:23 PM, Amos Jeffries <> 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