[tz] Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt
murch at fastmailteam.com
Wed Mar 8 14:50:51 UTC 2023
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
> and cite Resolution 4 of the 27th CGPM (2022)
> 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.
Cyrus Development Team
FastMail Pty Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz