Re: [Last-Call] [Sedate] Genart last call review of draft-ietf-sedate-datetime-extended-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Wednesday, June 14, 2023 07:51 -0500 Robert Sparks
<rjsparks@xxxxxxxxxxx> wrote:

>...
>>> The definition of UTC has a a short bit of history in it
>>> that is interesting, but unnecessary for this document.
>>> Consider removing from "From 1972" to the end of the first
>>> paragraph of the definition. (If you want to point to
>>> history, choose a rich informational reference perhaps).

>> I don't think that it helps to remove information from this
>> definition. The main point here is that UTC is something very
>> specific, the definition of which changed over time (and
>> actually started only in 1972). (And that GMT is no longer a
>> valid name for UTC.)

> Maybe saying that explicitly is better than trying to get the
> reader to infer it from such a small synopsis of history. And
> I wasn't suggesting removing the sentence about GMT.

Concur (and commenting here only because Robert has stated a
principle that I think applies elsewhere in the I-D as well,
including things I covered in my last two notes).  If we have a
point to make, let's make it.  The statement about GMT is
actually a good example although I'd be tempted to go further
than "an earlier timescale" and include something about a zone
specific to the UK.  This is different from the Section 2
discussion but shares a key property with it: the UTC definition
would be considerably improved if it were clearly a definition,
preferably with a normative reference (not just to leap
seconds).  Then, if you think a mini-history lesson is useful,
make it clearly separate.

FWIW, your brief explanation of the status of "GMT" appears to
be inconsistent with the last paragraph of the IANA description
[1].  It would be reasonable to include a provision in your IANA
Considerations section specifying that be sorted out.  IMO, that
should not require an update to BCP 175; worst case, IANA could
add a sentence pointing to this document and adding the
"mistakenly referred to" bit. 

The current description also raises a question: My reading of
the TZ database indicates that "GMT" is still a valid zone name,
associated (at least) with British time in the winter and maybe
the summer too.  It certainly was pre-1972.  Would that not make
a reference to 
   1965-04-01T00:00+00:00[GMT]  and/or
   1965-04-01T00:00+00:00[Europe/GMT]
valid? How about
   2020-12-25T00:00:00+00:00[Europe/GMT]   ?   
   Do those cases not put the current "GMT" sentence, which can
be read to imply than any appearance of "GMT" is a mistake, in
need of further clarification?

>...

>> We could divulge that the definition is adapted from RFC
>> 3339, but I don't see a strong need to do that.
> 
> I yield.
> 
> (I'll save my quibble for some future argument that is opening
> 3339 up more thoroughly.)

Ok with me as long as it is clear that this issue, and the
exclusion of future dates, are lingering there and that someone
(Murray?  Murray as acting-Francesca?) is keeping track of the
issue.  In particular, the CALEXT work, including the documents
that have already been through iETF LC, should be reviewed to be
sure that they do not accidentally reopen these issues.

>...

best,
    john

[1] https://data.iana.org/time-zones/tz-link.html#tzdb

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux