Re: [Sedate] Can offsets like [+02:00] be used instead of IANA names in brackets?

Justin Grant <justingrant.ietf.public@gmail.com> Fri, 18 March 2022 01:14 UTC

Return-Path: <justingrant.ietf.public@gmail.com>
X-Original-To: sedate@ietfa.amsl.com
Delivered-To: sedate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F13A1774 for <sedate@ietfa.amsl.com>; Thu, 17 Mar 2022 18:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9BAk8_p37oz for <sedate@ietfa.amsl.com>; Thu, 17 Mar 2022 18:14:40 -0700 (PDT)
Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4839F3A176F for <sedate@ietf.org>; Thu, 17 Mar 2022 18:14:40 -0700 (PDT)
Received: by mail-oo1-xc34.google.com with SMTP id p10-20020a056820044a00b00320d7d4af22so8604033oou.4 for <sedate@ietf.org>; Thu, 17 Mar 2022 18:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CMv23tkVs/PquSvdZz+oxedD/c/msu78JyQsTf+TYTs=; b=ASNmGACcKvHJQDI+tfbGOYLtyhqmns289y40Iq7MpucduC0IrmmiVzCjPk+/imhnf5 GrJTIRd71VxLZbjHXG1Yvz0TyVJIyliIa8ly6zkKujTiU7FSrSleT+WDv9IZmXBtP3cB uU87lTLkETUZ92i4NvkL1QvsAqq3PfMUpDYIm9N43jLtEwYGCj7iM0GB1afBEha+kR93 L3bLE9b4QnSK2o/1M1aV/meTxRpvvosX07h2tuzAlBHP+xVmn3JaqmGU3HfoVDmQ+scW vab9BVQafQkgM3FRt8QEcNCCjvMrAwDnsnFEGdZqynoPyh/oI3eclItHJShBYOd8zEqP yDLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CMv23tkVs/PquSvdZz+oxedD/c/msu78JyQsTf+TYTs=; b=ttx+LvAEFy4jfCrWuj4Z07k30b3L6IgL/jDO+/Kb4lnnsbM2mK7gf+Rr0pSl2VNTyt hHZ+g4aABEuEJ4zZNrIq7YuKbJ020pybToK2dMlhHubKnsyaU3+Cq1TVTg3O9xAnFdIE iNokuuayhks9OVEymme6+Wuo/q2vjVHRtfoGrhZIge9WSOM2hdN5G50gfgUcDYsV3PrU BYV4PnasLocbmq4j0HGouFa3Ae1HwZcZjWlyptrtZy5BTJEeDwbrVEZF2HpU4saI0WEI oc9wOp+X2wM/d4Em76LFwnht3j9cgsdu5Q2XTu026CqvBSF7JH+aoZ7nqMI6ZGAvKdSI dZLA==
X-Gm-Message-State: AOAM533L+fFfP/PTLrThWTF6M00BoQ2gT1Yk6NXkxOL8vhNj5hj3OAcu nSSKtOXfIfuc4UNjinczOxZo5CrBaUlagPcDKSw=
X-Google-Smtp-Source: ABdhPJxKc9YvSR1grKXGJK0bS5hRi+M3t5xwonIV3gaIi7mrzyob8ghQ3BpubEzM5N52P3xCRCK4WP8ui2m7Hz+tWTw=
X-Received: by 2002:a05:6871:a5:b0:d4:41d7:d341 with SMTP id u37-20020a05687100a500b000d441d7d341mr6830797oaa.6.1647566079090; Thu, 17 Mar 2022 18:14:39 -0700 (PDT)
MIME-Version: 1.0
References: <CACy7CfhB63dgxatWHYSr-KMKP1SWwd6nRmumCSCPVijgYede4A@mail.gmail.com> <c8035af7-1302-a04a-e449-76db3ad1754e@igalia.com> <6D38910C-72A3-4133-A9BF-794B532765DF@tzi.org> <CACy7Cfgw42p4e0squf0=Ji=RPau+ASeTWd=D6syK5=WUXpfvDw@mail.gmail.com> <A5B6B601-F5B1-469F-B442-3D008519D24B@tzi.org> <CACy7CfhxiOOy0BMdAgx2Jaiomnq6GvEqhamUmOwgdWB6oyKY3w@mail.gmail.com> <63BE08D0-C7C5-4CEA-BBE2-640C8F126661@tzi.org> <f6645a58-74f4-31f4-edd7-85d3d1b91851@igalia.com> <CACy7CfitzT5qDh68P5ZBRDSMAKwSWozWgg9yTJAT2AX9S_VD_A@mail.gmail.com> <VI1PR0202MB34246D8D790A3B6BC4A76E9F870A9@VI1PR0202MB3424.eurprd02.prod.outlook.com> <CACy7CfgwehrwckoG1TuFVCf6c0xvCtiq-QLSzDTAdru9NmvUaw@mail.gmail.com> <85522526-B023-415A-8E36-83021721FC9F@tzi.org>
In-Reply-To: <85522526-B023-415A-8E36-83021721FC9F@tzi.org>
From: Justin Grant <justingrant.ietf.public@gmail.com>
Date: Thu, 17 Mar 2022 18:14:27 -0700
Message-ID: <CACy7CfhJ4tPjexbtN45mv+3gNuY46NnZfM7OTDP2e9uzfmzs=Q@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Edward Welbourne <edward.welbourne@qt.io>, Ujjwal Sharma <ryzokuken@igalia.com>, "sedate@ietf.org" <sedate@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e364b205da73de59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sedate/fQ0I7_p9FhllmkHhUMKfb9A978c>
Subject: Re: [Sedate] Can offsets like [+02:00] be used instead of IANA names in brackets?
X-BeenThere: sedate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Serialising Extended Data About Times and Events <sedate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sedate>, <mailto:sedate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sedate/>
List-Post: <mailto:sedate@ietf.org>
List-Help: <mailto:sedate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sedate>, <mailto:sedate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2022 01:14:45 -0000

>
> Declaring consensus is the remit of the WG chairs, but as an editor of the
> WG draft I’m hearing clear direction from the WG to include this in the
> next revision of the draft.


OK sounds good. I wasn't sure of the right IETF term for the current state.
Thanks for your correction.

Can’t merge issues, but I’m looking at
> https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/15


Oops! Thanks for catching this copy/paste mistake!

Why is it necessary to deviate from the definition of Zulu time in RFC 3339
> (adding a plus)?


Could you explain further?  Not sure I understand this objection. Feel free
to just comment inline in the PR and I can edit the PR as needed.

The current PR defines a few terms but then doesn’t use them; the editors
> can supply the necessary glue.
> The discussion here so far can probably provide some guidance on what the
> semantics of this form are.


Sounds good. Let me know if you'd like me to keep editing that PR or if
you'd like to take it forward. I'm OK either way.

I’d prefer to have references to the specifications (RFCs?) relevant for
> the IANA timezone database; the PR text leaves that as an exercise to the
> reader.  So if the WG can point us to the documents that you want to have
> referenced, that might help reducing ambiguity.


I don't know if the TZDB identifiers are included in any standard.
https://www.rfc-editor.org/rfc/rfc6557.html defines the process for
maintaining the TZDB, but I'm not sure if the data itself is covered by any
standards. Does anyone on this list have insight about this topic?

Cheers,
Justin


On Thu, Mar 17, 2022 at 12:29 PM Carsten Bormann <cabo@tzi.org> wrote:

> On 2022-03-17, at 18:01, Justin Grant <justingrant.ietf.public@gmail.com>
> wrote:
> >
> > I'm hearing consensus on this thread that it's OK to add offset strings
> in brackets, e.g. "2021-12-09T00:00-08:00[-08:00]" in order to be
> compatible with prior art in java.time.ZonedDateTime. Caveat: this format
> is allowed but is generally not recommended because of the issues noted by
> @Edward Welbourne and others. Documentation should discourage but not
> prohibit use of this format.
>
> Declaring consensus is the remit of the WG chairs, but as an editor of the
> WG draft I’m hearing clear direction from the WG to include this in the
> next revision of the draft.
>
> > Does anyone object?
> >
> > If not, can we merge
> https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/12
> ?
>
> Can’t merge issues, but I’m looking at
> https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/15
>
> The current PR defines a few terms but then doesn’t use them; the editors
> can supply the necessary glue.
> The discussion here so far can probably provide some guidance on what the
> semantics of this form are.
>
> Why is it necessary to deviate from the definition of Zulu time in RFC
> 3339 (adding a plus)?
>
> I would like to avoid discussing the weird legacy Etc/GMT timezones
> (exhibit 1: PR#15 gets this wrong).
>
> I’d prefer to have references to the specifications (RFCs?) relevant for
> the IANA timezone database; the PR text leaves that as an exercise to the
> reader.  So if the WG can point us to the documents that you want to have
> referenced, that might help reducing ambiguity.
>
> Grüße, Carsten
>
>