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

From: Justin Grant <[email-masked]>
Date: Mon, 7 Mar 2022 15:22:27 -0800

The current ABNF for the time zone extension does not support offset time
zones, e.g. [+08:45]. Offset zones are supported in java.time, which is the
prior art driving the bracketed time zone extension format. Should the
standard also allow offsets in brackets too?

https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/12
has discussion relevant to this question.

FWIW, in the design of Temporal we've assumed that we should support
offsets in brackets for compatibility with Java. Here's a Java example:

public class MyClass {
    public static void main(String args[]) {
      java.time.ZonedDateTime zdt =
java.time.ZonedDateTime.parse("2021-12-09T00:00-08:00[-08:00]");
      System.out.println(zdt.toString());
    }
}

Cheers,
Justin Grant

---

From: Ujjwal Sharma <[email-masked]>
Date: Tue, 8 Mar 2022 21:32:54 +0530

While this format certainly looks weird, I believe we should include it 
for backwards compatibility with the de-facto standard. Any compelling 
arguments to avoid this at all costs?

Ujjwal

On 08/03/2022 04.52, Justin Grant wrote:
> The current ABNF for the time zone extension does not support offset 
> time zones, e.g. [+08:45]. Offset zones are supported in java.time, 
> which is the prior art driving the bracketed time zone extension format. 
> Should the standard also allow offsets in brackets too?
> 
> <https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/12> 
>        java.time.ZonedDateTime  zdt=  java.time.ZonedDateTime.parse("2021-12-09T00:00-08:00[-08:00]");

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Mar 2022 17:08:17 +0100

On 2022-03-08, at 17:02, Ujjwal Sharma <[email-masked]> wrote:
> 
> While this format certainly looks weird, I believe we should include it for backwards compatibility with the de-facto standard. Any compelling arguments to avoid this at all costs?

Does this need to be compatible to the Java API or to some one-the-wire format?

For the latter, I’d like to focus on the [foo=bar] format as far as that is possible.

Grüße, Carsten

---

From: Justin Grant <[email-masked]>
Date: Tue, 8 Mar 2022 10:35:10 -0800

To have compatibility with java.time.ZonedDateTime, strings like
"2021-12-09T00:00-08:00[-08:00]" would need to be valid in the standard.
Java currently both parses and emits that format.

Does that answer your question?

Cheers,
Justin

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Mar 2022 20:56:54 +0100

> Does that answer your question?

Yes, thank you.

So we would have a second exception to the [foo=bar] syntax, beyond just the timezone name.

Grüße, Carsten

---

From: Justin Grant <[email-masked]>
Date: Tue, 8 Mar 2022 12:19:02 -0800

Yes. Although I'd probably frame it as expanding the syntax of time-zone in
our ABNF to also allow time-numoffset from RFC 3339 section 5.6.

IMO, "*second exception to the [foo=bar] syntax*" sounds like
[-08:00][America/Los_Angeles] could be allowed in a string, when in reality
the time zone suffix should be mutually exclusive: either an IANA name or a
numeric offset string.

Cheers,
Justin

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Mar 2022 21:20:21 +0100

On 2022-03-08, at 21:19, Justin Grant <[email-masked]> wrote:
> 
> IMO, "second exception to the [foo=bar] syntax" sounds like [-08:00][America/Los_Angeles] could be allowed in a string, when in reality the time zone suffix should be mutually exclusive: either an IANA name or a numeric offset string.

Ah, that’s the part I missed.
So what is the reason these are mutually exclusive?

Grüße, Carsten

---

From: Ujjwal Sharma <[email-masked]>
Date: Wed, 9 Mar 2022 02:26:31 +0530

I believe the Java format only allows one bracketed suffix, but also it 
won't be quite useful to have two conflicting pieces of information.

Why *did* Java support offsets in the brackets, however, is not known to 
me. Perhaps we could ask Stephen Colebourne 
(https://twitter.com/jodastephen)?

Ujjwal

---

From: Justin Grant <[email-masked]>
Date: Tue, 8 Mar 2022 12:58:04 -0800

The purpose of the time zone extension is to allow senders to tell
receivers about the time zone of the timestamp. A timestamp can only have
one time zone, so therefore there should only be one time zone extension.

An IANA name in brackets means "receiver, please use your TZDB rules to
decide how to calculate the offset of derived timestamps like "1 day later"
An offset string in brackets means "receiver, I am opting out of using time
zone rules. Instead, every derived timestamp should use this offset."

A good question is why not just use a bracketless RFC 3339 string to
indicate opting out of using TZDB rules?  The main reason is that it'd
unnecessarily break compatibility with existing Java code.

But there's another reason too. Programs that create DST-aware derived
values (e.g. "one day later") from an input string should require bracketed
timezone annotations and therefore should fail parsing if the annotation is
missing. Doing this ensures that senders won't inadvertently pass an RFC
3339 timestamp (with no awareness of its time zone) to a program that needs
the time zone to calculate derived values.  But if the sender wants to opt
out of time zone processing, then using an extension like [-08:00] allows
that escape hatch without opening up the receiving program to bugs caused
by senders accidentally omitting the time zone annotation from the string.

Note that offset time zone annotations won't be a common case. It's an
escape hatch for cases where the time zone is not known, and when the
sender wants to tell the receiver that they're OK with it being unknown.
Had Java not accepted this syntax we probably wouldn't add it, but given
that Java does support this syntax and it's been in wide use for 10+ years,
it seems prudent to accept it in the standard.

Cheers,
Justin

On Tue, Mar 8, 2022 at 12:56 PM Ujjwal Sharma <[email-masked]> wrote:

> >> IMO, "second exception to the [foo=bar] syntax" sounds like

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 08 Mar 2022 15:58:32 -0500

> So what is the reason these are mutually exclusive?

The same reason that `[Australia/Melbourne][Australia/Sydney]` is mututally exclusive.  They're two different "timezone" fields.  Or even `[Etc/GMT+8][-08:00]` is mutually exclusive.  They're two different copies of the same field.  Except that the Etc/GMT family don't do partial hour offsets, so we can't just use that syntax exclusively.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Edward Welbourne <[email-masked]>
Date: Wed, 9 Mar 2022 10:01:59 +0000

Justin Grant (8 March 2022 21:58) wrote:
> An IANA name in brackets means "receiver, please use your TZDB rules
> to decide how to calculate the offset of derived timestamps like "1
> day later" An offset string in brackets means "receiver, I am opting
> out of using time zone rules. Instead, every derived timestamp should
> use this offset."

One warning here: if the sender only tells the receiver the offset of a
particular time and stipulates another time as "one day later", or
similar, the resulting time will be expressed relative to that offset
*which might not match* the sender's time-zone for that time (due to a
transition in the interval), so may produce different results than if
the sender had reported their zone's IANA ID.  That is potentially
desirable in some cases, of course, but the documentation of the choice
of annotation should make clear that the two forms are not always
equivalent.

	Eddy.

---

From: Justin Grant <[email-masked]>
Date: Thu, 17 Mar 2022 10:01:08 -0700

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 <[email-masked]> and others. Documentation should
discourage but not prohibit use of this format.

Does anyone object?

If not, can we merge
 ?

Cheers,
Justin

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Mar 2022 20:29:13 +0100

On 2022-03-17, at 18:01, Justin Grant <[email-masked]> 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

---

From: Justin Grant <[email-masked]>
Date: Thu, 17 Mar 2022 18:14:27 -0700

>
> 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.

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 <[email-masked]> 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
> Can’t merge issues, but I’m looking at
> https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/15
>
> 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
>
>

---

From: Edward Welbourne <[email-masked]>
Date: Fri, 18 Mar 2022 11:11:31 +0000

>> https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/15

Added some comments (as ediosyncratic).

>> 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.

Justin Grant (18 March 2022 02:14) replied:
> 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?

I think
https://www.iana.org/time-zones/repository/theory.html#naming
is about as close as you'll get; see the rest of the page for further
details.  (Link derived from tz/CONTRIBUTING.)

	Eddy.

---

From: Paul Eggert <[email-masked]>
Date: Fri, 18 Mar 2022 13:01:17 -0700

On 3/17/22 19:22, Michael Douglass wrote:
> Paul - would you like to respond to the last question below on tzdb 
> identifiers?...

> -------- Forwarded Message --------
> Date:     Thu, 17 Mar 2022 18:14:27 -0700
> From:     Justin Grant <[email-masked]>
> ...

As TZDB itself says in 
<https://data.iana.org/time-zones/tz-link.html#changes>, "The tz code 
and data are by no means authoritative."

Even now, a TZDB name like "Asia/Hebron" doesn't uniquely specify the 
mapping from UTC to local time; you also need a TZDB version string like 
"2022a", because the data for Asia/Hebron changed in 2022a vs the 
previous version.

Also, I know of at least two efforts to fork TZDB, though none have 
published official versions yet. If and when that happens, you may also 
need to specify the source for your TZDB data to specify what the 
mapping is.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 21 Mar 2022 19:00:22 +0100

On 18 Mar 2022, at 21:01, Paul Eggert wrote:

> I know of at least two efforts to fork TZDB, though none have 
> published official versions yet. If and when that happens, you may 
> also need to specify the source for your TZDB data to specify what the 
> mapping is.

Is this something that has been communicated to the IAB? Seems like some 
"liaising" might be in order. Having conflicting forks seems less than 
ideal.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Paul Eggert <[email-masked]>
Date: Mon, 21 Mar 2022 11:15:20 -0700

> "liaising" might be in order. Having conflicting forks seems less than 

I haven't communicated it, no. Feel free to pass it along.

You're right it's less than ideal. Luckily the forks are more 
philosophical than practical, as the differences are minor and affect 
only pre-1970 timestamps. 1970 has long been the TZDB cutoff anyway, as 
it would not be practical to cover the world before 1970 in a reliable way.