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

[Ken Murchison]

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.

-- 
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20230308/201207e1/draft-murchison-rfc8536bis.diff-0001.html>