[tz] Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt

[Brian Inglis]

On 2023-03-08 07:50, Ken Murchison via tz wrote:
> Attached is the diff between my working copy and -06.  Comments and suggested 
> text welcome.
> I wonder if we need to add a definition of "leap second table expiration".
> On 3/7/23 5:59 PM, Paul Eggert wrote:
>> In rereading the draft I found a couple of technical issues.
>> 1. Most of this draft was written before the recent announcement that leap 
>> seconds are possibly being discontinued. As I understand it, this proposal is 
>> likely but not yet set in stone. Perhaps we need a sentence or two about this 
>> in the draft? Something like the following at the first mention of leap second 
>> expiry:
>> "If leap seconds become permanently discontinued, as requested by the General 
>> Conference on Weights and Measures[*], the leap second table SHOULD NOT expire 
>> since it will not be updated in the foreseeable future."
>> and cite Resolution 4 of the 27th CGPM (2022) 
>> <https://www.bipm.org/en/cgpm-2022/resolution-4>.
>> 2. The use of TZ strings like 'XXX3EDT4,0/0,J365/23' is described confusingly, 
>> since 3.3.1 says that this is not an extension to POSIX (i.e., we're just 
>> spelling out what POSIX says, so this is not a TZ string extension), whereas 
>> the title of 3.3.1 says "TZ String Extensions". Because section 4 says a 
>> writer should generate a version 3 file (which can contain TZ string 
>> extensions) only if necessary, it's too easy to read this as saying that if 
>> the TZif file contains a TZ string like 'XXX3EDT4,0/0,J365/23' then it must be 
>> at least version 3 - which is not how current zic behaves (it's just version 
>> 2). (This confusion is my fault; sorry.)
>> To fix this, how about if we move the text and example in the bullet point "* 
>> DST is considered to be in effect all year ..." up from section 3.3.1 to 
>> section 3.3, with minor wordsmithing to continue to make it clear that we're 
>> only spelling out POSIX more explicitly, not extending it. As a result of this 
>> wordsmithing, there will only be one POSIX extension (extending hours to -167 
>> through 167).
>> I suppose we should also should note that a future version of POSIX is likely 
>> to adopt the POSIX extension documented in 3.3.1. Even if that happens, 3.3.1 
>> will still considered to be an extension, in that TZif files using it will 
>> still need to be marked version 3 or later.

Suggest using alternative rather than Daylight Savings Time as under current 
POSIX Base Definitions 8.3 Other Environment Variables TZ:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

"std and dst
Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the 
designation for the standard (std) or the alternative (dst -such as Daylight 
Savings Time) timezone. Only std is required; if dst is missing, then the 
alternative time does not apply in this locale."...

as the alternative can be positive or negative (Ireland) and outside English 
North America, is mostly referred to as Summer or Winter time, or some 
equivalent expression in the local language, often advanced, normal, or retarded 
time in Latin languages e.g. NRC/CNR pubs for French Canada for an alternative:

https://nrc.canada.ca/fr/certifications-evaluations-normes/heure-officielle-canada/fuseaux-horaires-lheure-avancee

[default size may be large - <ctrl>-0 often normalizes!]

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry