Subject: [Sedate] A syntax proposal: floating and future times

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 07 Nov 2021 14:16:13 +1100

One of the biggest areas of debate in the meetings so far has been how to handle a mismatch between the zone and the offset, and whether to allow floating times.

I've had an idea in my head for a bit, so I figured I should write it out in advance of our meeting next week!

The basic principles are:
 * the special name 'floating' is used to specify that the timezone will be resolved at the point of display or use
 * the zone in brackets is advisory only, the offset always wins
 * the namespace 'tz' specifies a timezone which overrides the offset.  That means that a time with a 'tz' namespace may be different than timestamp defined purely by the RFC3339 part, thought it's recomended to use the best-guess at what the offset is likely to be in the timestamp, so that systems which don't understand this extension still give as good position as possible.

My example timepoint will be 9am on my birthday - not this year, but next year - giving enough time for some likely changes to happen.  So that's

`2022-11-26T09:00:00`

I expect that I'll probably be at home when I create this, so by default I would create one of these:

`2022-11-26T09:00:00+11:00`
`2022-11-26T09:00:00+11:00[Australia/Melbourne]`

These both mean `2022-11-25T22:00:00Z` and always will, no matter when they are resolved.

*Changes to zone offsets**
*

Let's suppose the the Victorian government decided to join with Queensland and stop doing daylight saving next year, so "Australia/Melbourne" would then resolve to +10 in late November.  I could use this syntax:

`2022-11-26T09:00:00+11:00[tz=Australia/Melbourne]`

Which would start out as `2022-11-25T22:00:00Z` still, but would change to `2022-11-25T23:00:00Z` once the local zone database was updated.

*Floating time**
*
**
Suppose I just wanted to know when 9am was on my birthday, wherever I am in the world.  I would use something like:

`2022-11-26T09:00:00+11:00[tz=floating]`

(I'm happy bikeshed alternative syntax, e.g. `[tz-floating=true]` - just a clear way to specify this concept.  An advantage of having 'tz=' for both is that the "closest bound wins" rule applies - and you don't get confusion if both floating and a named timezone are specified on the same item - the first one always wins)

So if I'm still in Melbourne for my birthday next year, then it's the same as one of the above examples, but if I went to IETF115 in Madrid (assuming we go there for November next year!) and wound up still in Europe for a few weeks after, then it might resolve to `2022-11-26T08:00:00Z` for me, because I'd only be one hour ahead of UTC.

*While we're at it, what about TAI?**
*

Maybe I care about the alignment of the heavens at exactly 9am on my birthday being exactly 31536000 seconds since 9am Melbourne time on my birthday this year!  Maybe I could write:

`2022-11-26T09:00:00+11:00[tz-tai=37]`

Where 'tz-tai=N' defines the integer TAI offset that was expected to apply at the time.

Then if a leap second gets added or removed at the end of this year, this could resolve to a UTC date of:

`2022-11-25T21:59:59Z` or `2022-11-25T22:00:01Z`

(either way, it's the same TAI date of `2022-11-25T21:59:23`, regardless of leapseconds)

Obviously - these could all be stacked and the rules would be very clear about what to do, though it would be pretty weird to care about the exact TAI offset but NOT the exact UTC offset.

...

I think this is all consistent and easily implementable.

In particular, it creates clarity around handling:
 * If you specify an unadorned timezone, then the timezone is advisory and the offset always wins.
 * If you specify anything with the 'tz' namespace, then the offset is advisory and the timezone information overrides at the point when the date is resolved.
 * If the timezone can't be resolved, then the offset can be used as a fallback - so implementations SHOULD use their best guess as to the offset that is likely to be meaningful (e.g. local timezone of the user or system that created the date)

Regards,

Bron.

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Nov 2021 00:11:06 +0100

On 2021-11-07, at 04:16, Bron Gondwana <[email-masked]> wrote:
> namespace 'tz’ 

Just a terminology thing:  In your proposal, “tz” is not a namespace but an extension name.  It is a nice example why we usually don’t need namespaces.

(“tz-foo” and “tz-bar” could be considered to open a “tz” namespace.  But this could be simply done by reserving extension name prefixes for a specific purpose…)

Grüße, Carsten

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 08 Nov 2021 15:11:34 +1100

On Sun, 7 Nov 2021, at 14:16, Bron Gondwana wrote:
> *Floating time*

This is not floating time. You've given it an offset: +11h. I don't understand this proposal at all. We already have a perfectly good syntax for a floating (a.k.a. wall-clock) date-time, in fact you used it earlier:

`2022-11-26T09:00:00`

It's the one that everyone already intuitively uses for this. The only thing that's needed is to give it a name so it can be more easily referenced from other documents.

—Neil

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 08 Nov 2021 15:23:52 +1100

> This is not floating time. You've given it an offset: +11h. I don't understand this proposal at all. We already have a perfectly good syntax for a floating (a.k.a. wall-clock) date-time, in fact yo…

Yes, but... the problem is that this is NOT an RFC3339 plus an extension, it's a subset of RFC3339.  So by putting the offset and the extension to say "adjust the offset to the current timezone", you get a treatment of floating which is basically "local time but we don't know the location/timezone yet".

Just like with the "localtime, zone overrides offset" version, there's still an offset hint.  This is different to ICALENDAR times, because this format currently always requires an exact timepoint in RFC3339 syntax, even if that timepoint might be adjusted if the offset no longer matches the zone once the zone is resolved.

> It's the one that everyone already intuitively uses for this. The only thing that's needed is to give it a name so it can be more easily referenced from other documents.

Ok... only, when this was proposed at the last IETF, there was fairly strong pushback to the idea of the first part not being exactly an RFC3339 production - so I'm proposing a format which always contains an RFC3339 component and yet is reliably convertable.  You can always do:

`2022-11-26T09:00:00Z[tz=floating]`

Which has identical meaning to the +11:00 example I gave above, except that if you don't know which zone to float into, it defaults to UTC - which is what at least Cyrus IMAPd does when it gets a floating time and has no timezone context (and the early bugs we had with alarms at the wrong time were precisely that - because there was no zone information in the alarm daemon until we figured out how to pass it down from the calendar default)

So you can reliably convert from this format into ICALENDAR's offsetless floating time, and reliably convert back by using 'Z' and [tz=floating].

Bron.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 08 Nov 2021 15:51:14 +1100

> Yes, but... the problem is that this is NOT an RFC3339 plus an extension, it's a subset of RFC3339.  So by putting the offset and the extension to say "adjust the offset to the current timezone", y…

It strikes me then that the fundamental problem here is that the goal is really to create a standardised serialisation of some date formats **that are not datestamps**, that are commonly used across applications on the web. It should use the same elements of syntax as RFC3339 but it's not exactly an "extension". All the problems seem to stem from trying to enforce that they can also be treated as single points in time.

—Neil

---

From: Justin Grant <[email-masked]>
Date: Sun, 7 Nov 2021 23:40:55 -0800

>
> *Changes to zone offsets*

My understanding is that there's three use cases:
1. The sender wants to keep the instant fixed, even if the offset of the
time zone has changed (this may result in a different local time than what
was originally captured)
2. The sender wants to keep the local time fixed, even if the offset of the
time zone has changed (this may result in a different instant than what was
originally captured)
3. The sender has no opinion. It will send both the offset and the time
zone to the receiver, and it wants the receiver to decide what to do if the
offset of the time zone has changed.

Here's how Temporal is currently (modulo whatever we decide here in
SEDATE!) planning to handle these three cases:
1. Keep instant fixed by specifying a Z offset with a time zone annotation,
e.g. 2022-11-26T09:00:00Z[Australia/Melbourne]
2. Keep local time fixed by omitting the offset from the string, e.g.
2022-11-26T20:00:00[Australia/Melbourne]
3. Send both local time and offset, and leave it up to the receiver to
decide what to do, e.g. 2022-11-26T20:00:00+11:00[Australia/Melbourne]

What do folks think about those three syntaxes?

For case (2), I'm not sure why we'd need a separate [tz=] syntax for this
case, but maybe I'm missing something?

2022-11-26T09:00:00Z[tz=floating]

I admit I don't fully understand the use case for this syntax. If you know
the instant but not the time zone, then why isn't
2022-11-26T09:00:00Z sufficient?
If you know the local time but not the instant, then why isn't
2022-11-26T09:00:00 sufficient? If the only point of [tz=floating] is to
notify the receiver that you don't know the time zone, then why not just
omit the time zone annotation completely?

It strikes me then that the fundamental problem here is that the goal is
> really to create a standardised serialisation of some date formats *that
> are not datestamps*, that are commonly used across applications on the
> web. It should use the same elements of syntax as RFC3339 but it's not
> exactly an "extension". All the problems seem to stem from trying to
> enforce that they can also be treated as single points in time.

Yep, I'm inclined to agree with Neil here. When sending a partial zoned
timestamp (e.g. I don't know the offset, or I know the timezone), I think
the most obvious way to express "I don't know X" is to omit "X" from the
string. I'm not sure it's a good idea to create a new syntax that pretends
that it's an RFC3339-compliant timestamp when it's really not.

when this was proposed at the last IETF, there was fairly strong pushback
> to the idea of the first part not being exactly an RFC3339 production - so
> I'm proposing a format which always contains an RFC3339 component and yet
> is reliably convertable.

Do we know why there was such strong pushback?  What were the underlying
concerns?

I don't know the people involved so can't be sure, but I'd guess that
adhering to RFC3339 syntax but not actually providing a meaningful
timestamp would generate *more* pushback. But that's just a guess.

Cheers,
Justin

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Nov 2021 08:56:28 +0100

On 8. Nov 2021, at 08:40, Justin Grant <[email-masked]> wrote:
> 
>  I'm not sure it's a good idea to create a new syntax that pretends that it's an RFC3339-compliant timestamp when it's really not.

This.

>> when this was proposed at the last IETF, there was fairly strong pushback to the idea of the first part not being exactly an RFC3339 production - so I'm proposing a format which always contains an RFC3339 component and yet is reliably convertable.
>> 
> Do we know why there was such strong pushback?  What were the underlying concerns?

There was (and still is, at least in my mind) confusion on how much SEDATE thingies (we need a name for them) are 
(1) RFC 3339 extended
(2) almost, but not entirely unlike RFC 3339.

RFC 3339 is for 
(a) UTC-referenced timestamps, possibly annotated with a UTC offset.
This annotation could be extended by SEDATE to provide an annotation what timezone that UTC offset stands for.
But this is additional information; the meaning otherwise doesn’t change.

The pushback was about leaving the territory of (a), because some people wanted SEDATE to be (a) only.

Some proposals/use cases here

(b) are almost timestamps, but reference a timezone with the intent to update the actual time stamp based on changes to the timezone;
(c) are not timestamps at all, but user-visible indications of intent that only make sense in the context of a specific user (“floating”).

(b) is still mostly deterministic (i.e., there are usually ways to find out how a timezone changes, so after a little period of confusion people again agree what timestamp is/was meant).

(c) is maybe a form of calendaring, but surely not a timestamp, because its interpretation changes by who looks at it.
It should most definitely not look like RFC 3339 (e.g., by leaving out offset info).

By the way, the military character for “local time” is “J" (where “Z” is world time), so the natural way to say

2022-11-26T09:00:00🤦‍♂️[tz=floating]

is

2022-11-26T09:00:00J

Not RFC 3339, and clearly saying that this is not a timestamp unless context is added.

Grüße, Carsten

---

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 08 Nov 2021 01:33:01 +0530

CCing Temporal champions mailing list for greater visibility

On Sun, Nov 7 2021 at 14:16:13 +1100, Bron Gondwana 
<[email-masked]> wrote:
> One of the biggest areas of debate in the meetings so far has been 
> how to handle a mismatch between the zone and the offset, and whether 
> to allow floating times.
> 
> the special name 'floating' is used to specify that the timezone will 
> be resolved at the point of display or use
> the zone in brackets is advisory only, the offset always wins
> the namespace 'tz' specifies a timezone which overrides the offset.  
> That means that a time with a 'tz' namespace may be different than 
> timestamp defined purely by the RFC3339 part, thought it's recomended 
> to use the best-guess at what the offset is likely to be in the 
> timestamp, so that systems which don't understand this extension 
> still give as good position as possible.
> 
> My example timepoint will be 9am on my birthday - not this year, but 
> next year - giving enough time for some likely changes to happen.  So 
> that's
> 
> 2022-11-26T09:00:00
> 
> 2022-11-26T09:00:00+11:00
> 2022-11-26T09:00:00+11:00[Australia/Melbourne]
> 
> These both mean 2022-11-25T22:00:00Z and always will, no matter when 
> they are resolved.
> 
> Changes to zone offsets
> 
> Let's suppose the the Victorian government decided to join with 
> Queensland and stop doing daylight saving next year, so 
> "Australia/Melbourne" would then resolve to +10 in late November.  I 
> could use this syntax:
> 
> 2022-11-26T09:00:00+11:00[tz=Australia/Melbourne]
> 
> Which would start out as 2022-11-25T22:00:00Z still, but would change 
> to 2022-11-25T23:00:00Z once the local zone database was updated.
> 
> Floating time
> 
> Suppose I just wanted to know when 9am was on my birthday, wherever I 
> am in the world.  I would use something like:
> 
> 2022-11-26T09:00:00+11:00[tz=floating]
> 
> (I'm happy bikeshed alternative syntax, e.g. [tz-floating=true] - 
> just a clear way to specify this concept.  An advantage of having 
> 'tz=' for both is that the "closest bound wins" rule applies - and 
> you don't get confusion if both floating and a named timezone are 
> specified on the same item - the first one always wins)
> 
> So if I'm still in Melbourne for my birthday next year, then it's the 
> same as one of the above examples, but if I went to IETF115 in Madrid 
> (assuming we go there for November next year!) and wound up still in 
> Europe for a few weeks after, then it might resolve to 
> 2022-11-26T08:00:00Z for me, because I'd only be one hour ahead of 
> UTC.
> 
> While we're at it, what about TAI?
> 
> Maybe I care about the alignment of the heavens at exactly 9am on my 
> birthday being exactly 31536000 seconds since 9am Melbourne time on 
> my birthday this year!  Maybe I could write:
> 
> 2022-11-26T09:00:00+11:00[tz-tai=37]
> 
> 2022-11-25T21:59:59Z or 2022-11-25T22:00:01Z
> 
> (either way, it's the same TAI date of 2022-11-25T21:59:23, 
> regardless of leapseconds)
> 
> Obviously - these could all be stacked and the rules would be very 
> clear about what to do, though it would be pretty weird to care about 
> the exact TAI offset but NOT the exact UTC offset.
> 
> ...
> 
> If you specify an unadorned timezone, then the timezone is advisory 
> and the offset always wins.
> If you specify anything with the 'tz' namespace, then the offset is 
> advisory and the timezone information overrides at the point when the 
> date is resolved.
> If the timezone can't be resolved, then the offset can be used as a 
> fallback - so implementations SHOULD use their best guess as to the 
> offset that is likely to be meaningful (e.g. local timezone of the 
> user or system that created the date)
> 
> Regards,
> 
> Bron.
> 
> --

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Nov 2021 09:19:35 +0100

> CCing Temporal champions mailing list for greater visibility

That doesn’t quite work, because it’s the discussion that contain the meat.

Please subscribe at
https://www.ietf.org/mailman/listinfo/sedate

To view past discussions, use the archive:
https://mailarchive.ietf.org/arch/browse/sedate/

Grüße, Carsten

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 08 Nov 2021 20:04:25 +1100

On Mon, Nov 8, 2021, at 18:40, Justin Grant wrote:
> 1. The sender wants to keep the instant fixed, even if the offset of the time zone has changed (this may result in a different local time than what was originally captured)
> 2. The sender wants to keep the local time fixed, even if the offset of the time zone has changed (this may result in a different instant than what was originally captured)
> 3. The sender has no opinion. It will send both the offset and the time zone to the receiver, and it wants the receiver to decide what to do if the offset of the time zone has changed.
> 
> Here's how Temporal is currently (modulo whatever we decide here in SEDATE!) planning to handle these three cases:
> 1. Keep instant fixed by specifying a Z offset with a time zone annotation, e.g. 2022-11-26T09:00:00Z[Australia/Melbourne]

I hate it - it's very human-unfriendly.  Either the Z means something different here (ick) or you just specified a time 11 hours after the time I specified in my example.

> 2. Keep local time fixed by omitting the offset from the string, e.g. 2022-11-26T20:00:00[Australia/Melbourne]

Oh - you specified all of them 11 hours later.  My examples were all 9am in my time, but you've gone for 8pm in my time.

This looks great except for one knotty problem - it's not an RFC3339 production.  Which is why my proposal, which keeps the RFC3339, and it very clear.

> 3. Send both local time and offset, and leave it up to the receiver to decide what to do, e.g. 2022-11-26T20:00:00+11:00[Australia/Melbourne]

This is the one that I specified as "offset wins".  There was a fair bit of interest, in the working group, in having the behaviour always well specified and not having "implementation defined" be a choice.

> For case (2), I'm not sure why we'd need a separate [tz=] syntax for this case, but maybe I'm missing something?

Not if you're allowed to trim the offset away from an RFC3339 date, no.  The 'tz' was there as a signifier of "the creator wants you to recalculate the offset before use.

> I admit I don't fully understand the use case for this syntax. If you know the instant but not the time zone, then why isn't  2022-11-26T09:00:00Z sufficient? If you know the local time but not the instant, then why isn't 2022-11-26T09:00:00 sufficient? If the only point of [tz=floating] is to notify the receiver that you don't know the time zone, then why not just omit the time zone annotation completely?

There are two reasons to use this over `2022-11-26T09:00:00`

1) so we keep the RFC3339 part intact.  I'm harping on about this because it's the entire point of my proposal.  Without that, the tz stuff is overkill.
2) it allows hinting of zone.  Hinting is optional of course, you could always use Z plus floating.  I don't know if explaining it out loud will help here.  I'll do up some nice slides anyway to see if I can make it clear.

(speaking of which - during the session I'll need to take my chair hat off to do this, so I'm glad I have Mark there to help)

> Yep, I'm inclined to agree with Neil here. When sending a partial zoned timestamp (e.g. I don't know the offset, or I know the timezone), I think the most obvious way to express "I don't know X" is to omit "X" from the string. I'm not sure it's a good idea to create a new syntax that pretends that it's an RFC3339-compliant timestamp when it's really not.
> 
> I don't know the people involved so can't be sure, but I'd guess that adhering to RFC3339 syntax but not actually providing a meaningful timestamp would generate *more* pushback. But that's just a guess. 

I guess we'll see :)  I'm not really attached to my idea or anything, but it's the proposal that was bouncing around in my head to satisfy the requirement for an RFC3339 basis.

Cheers,

Bron.

---

From: Justin Grant <[email-masked]>
Date: Mon, 8 Nov 2021 02:38:03 -0800

What I'm hearing from Bron (which I agree with) is that there should be a
standardized syntax for floating times like "10:00AM on 20 January 2025 in
Melbourne".  This is how calendaring apps will store future meetings. We
can bikeshed on specific syntax, but the high order bit is that this use
case is very important for interchange.

But there's also what Neil and Carsten are saying, which is that floating
times are "not timestamps", meaning they're not interchangeable with a
single number indicating time since eopch. This is also correct, and
forcing all timestamp-reading software to also know about floating times
seems bad. So I can understand why other IETF folks may be concerned about
backwards compat and would want the new RFC to be a strict superset of
RFC3339 syntax in order to make it easier to port software to the new RFC.

I'd suggest that one way to achieve both camps' goals might be to split the
RFC text into two buckets (I'm assuming sections in the same document):

*1. Timestamps + annotations*.

   - Superset of RFC 3339; 100% backwards-compatible syntax and semantics
   if the annotations are stripped off.  Interchangeable with a single numeric
   since-epoch value. For backwards-compat reasons, Z or numeric offset is
   always required in the string.
   - Timezones and other extension syntax is specified here.
   - Includes a decision about how to treat conflicts between timezone and
   (non-Z) offsets if both are present.  Choices include: always reject;
   always keep the instant unchanged; always keep local time unchanged; or "by
   mutual agreement of the communicating parties" because desired behavior
   varies by use case.

*2. Subsets of "timestamps + annotations".*  Like ISO 8601 defines subsets
of its syntax for different use cases, so can we. "10:00AM on 20 January
2025 in Melbourne" represents most calendar meetings in the world and is a
subset with every field except offset. We can bikeshed on the string syntax
for this subset, as long as it's *not* RFC 3339 because that will bring up
those backwards-compat concerns noted above.  This section could be
extended further in a later revision with more subsets, e.g. Time + Time
Zone ("9:00AM in Berlin").

I'm not suggesting different content, only a slightly different way to talk
about the same work that might be less concerning to folks whose top
priority is backwards compat. and/or precision around what is and is not a
timestamp.

Cheers,
Justin

On Mon, Nov 8, 2021 at 1:06 AM Bron Gondwana <[email-masked]> wrote:

> 2. The sender wants to keep the local time fixed, even if the offset of
> the time zone has changed (this may result in a different instant than what
> was originally captured)
> 1. Keep instant fixed by specifying a Z offset with a time zone
> annotation, e.g. 2022-11-26T09:00:00Z[Australia/Melbourne]
>
>
> I hate it - it's very human-unfriendly.  Either the Z means something
> different here (ick) or you just specified a time 11 hours after the time I
> specified in my example.
>
> Oh - you specified all of them 11 hours later.  My examples were all 9am
> in my time, but you've gone for 8pm in my time.
>
> This looks great except for one knotty problem - it's not an RFC3339
> production.  Which is why my proposal, which keeps the RFC3339, and it very
> clear.
>
> This is the one that I specified as "offset wins".  There was a fair bit
> of interest, in the working group, in having the behaviour always well
> specified and not having "implementation defined" be a choice.
>
> Not if you're allowed to trim the offset away from an RFC3339 date, no.
> The 'tz' was there as a signifier of "the creator wants you to recalculate
> the offset before use.
>
> the instant but not the time zone, then why isn't  2022-11-26T09:00:00Z sufficient?
> There are two reasons to use this over 2022-11-26T09:00:00
>
> 1) so we keep the RFC3339 part intact.  I'm harping on about this because
> it's the entire point of my proposal.  Without that, the tz stuff is
> overkill.
> 2) it allows hinting of zone.  Hinting is optional of course, you could
> always use Z plus floating.  I don't know if explaining it out loud will
> help here.  I'll do up some nice slides anyway to see if I can make it
> clear.
>
> (speaking of which - during the session I'll need to take my chair hat off
> to do this, so I'm glad I have Mark there to help)
>
> I guess we'll see :)  I'm not really attached to my idea or anything, but
> it's the proposal that was bouncing around in my head to satisfy the
> requirement for an RFC3339 basis.
>
> Cheers,
>
> Bron.
> --
> Sedate mailing list
> [email-masked]

---

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 08 Nov 2021 17:06:14 +0530

> https://mailarchive.ietf.org/arch/browse/sedate/

Yeah, I tried to loop the other ML in but that didn't work since folks 
didn't carry it forward. Anyway, I think Justin is doing a great job 
representing the champions here so we're good.

Ujjwal

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 08 Nov 2021 22:44:26 +1100

On Mon, 8 Nov 2021, at 21:38, Justin Grant wrote:
> What I'm hearing from Bron (which I agree with) is that there should be a standardized syntax for floating times like "10:00AM on 20 January 2025 in Melbourne".  This is how calendaring apps will store future meetings.

Just to be clear on terminology, in the calendaring world "floating time" specifically means "wall clock time", i.e. no time zone. The above example is just a date + time zone (but the exact UTC value could change if it's a future date and the time zone definition changes).

> I'd suggest that one way to achieve both camps' goals might be to split the RFC text into two buckets (I'm assuming sections in the same document):

That works for me.

—Neil

---

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 8 Nov 2021 17:31:37 +0530

Hello everyone!

First of all, thanks Bron for kicking some energy into this discussion.

On 08/11/2021 16.08, Justin Grant wrote:
> I'd suggest that one way to achieve both camps' goals might be to split 
> the RFC text into two buckets (I'm assuming sections in the same document):

I apologize for some of the initial misunderstanding in this thread, 
since it seems that I didn't manage to convey the updates from the 
previous IETF meetings to the Temporal champions very well and Justin 
seems to be a little out of the loop.

We received pushback in the past against allowing "timestamps" that are 
subsets of the RFC3339 format, which is why Bron made this proposal, 
which tries to reach a good middle-ground (it perfectly represents a 
floating time without relying on the non-standard format which omits the 
offset).

Now, as you mentioned, this is of course not ideal, since omitting the 
offset is simpler, though it comes at the cost of relying on a 
non-standard (atleast as of yet) representation. While I'm not opposed 
to standardizing this format, there are a number of folks who have their 
doubts regarding this subject, and therefore we decided to keep it 
off-limits for the time-being.

There's some ways we could try to standardize the subsets you mention 
without upsetting others, but IIUC that work is currently not in the 
scope of SEDATE as per the current charter.

One way I could imagine this being done would be to have a second RFC 
that reifies some of these subsets of the full 3339 format (eg: 
"floating date", "floating time", "floating datetime") and then we could 
change the current extension RFC to allow extending any of these formats 
in addition to the full 3339 format. The former could be a simple RFC, 
containing just the ABNF grammar for the supported formats as well as 
some motivating use-cases perhaps.

What do folks think? Would the RFC be within the scope of CALEXT 
instead? I'd believe so since a majority of the formats would have the 
strongest use-cases within the calendaring space.

Ujjwal

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

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: Shane Carr <[email-masked]>
Date: Mon, 8 Nov 2021 07:44:09 -0800

Two issues about storing a floating time with a time zone but not an offset
are (1) ambiguities around summer time transitions and (2) summer time
rules are subject to change.  Storing an offset along with the time zone
solves these issues, but introduces another: should the offset or the time
zone "win" in the case of a conflict?

In Temporal, we solve this via an API option called "offset" to declare the
intent.  There is a further "disambiguation" option to handle the summer
time conflict.

However, would it be useful if there were an annotation to declare the
intent within the datetime string?  Something like

2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=ignore]
2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=prefer]

---

From: Shane Carr <[email-masked]>
Date: Mon, 8 Nov 2021 07:41:52 -0800

In Temporal, we solve this via an API option
<https://tc39.es/proposal-temporal/docs/zoneddatetime.html#from> called
"offset" to declare the intent.  There is a further "disambiguation" option
to handle the summer time conflict.

---

From: Justin Grant <[email-masked]>
Date: Mon, 8 Nov 2021 09:43:59 -0800

For cases where the offset is known, but the sender wishes to communicate
their intent to prefer either offset or IANA name, then another extension
seems like a reasonable possibility to bikeshed. (Although it does break
backwards-compatibilty with RFC 3339 so I suspect it may get pushback from
folks who care more about backwards compat.)

But I think a more fundamental issue is that, at least as I undertsand it,
floating times as specified in RFC 5545 3.3.5
<https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5> are not
stored with an offset at all. The original offset is unknown.

      To properly communicate a
      fixed time in a property value, either UTC time or local time with
      time zone reference MUST be specified.

This is why I assumed that a subset was the only appropriate way to
serialize that offset-less data model, because one of the required
components was missing.

Cheers,
Justin

On Mon, Nov 8, 2021 at 8:13 AM Shane Carr <sffc=[email-masked]>
wrote:

> Two issues about storing a floating time with a time zone but not an
> offset are (1) ambiguities around summer time transitions and (2) summer
> time rules are subject to change.  Storing an offset along with the time
> zone solves these issues, but introduces another: should the offset or the
> time zone "win" in the case of a conflict?
>

---

From: [email-masked]
Date: Mon, 08 Nov 2021 11:13:31 -0800 (PST)

> > I'm not sure it's a good idea to create a new syntax that pretends that
> > it's an RFC3339-compliant timestamp when it's really not.

> This.

This is an interesting way to put it, and one I hadn't fully considered 
before. RFC 3339 specifies a syntax intended to express a particular semantic:
That of a fixed point in time, aka a timestamp. In previous discussions there
has been a lot of concern about extending the syntax for timestamps.

But if what's being represented is not, in fact, a particular point in time,
would it not in fact be better to use a syntax that's intentionally
incompatible?

This isn't a simple question with an obvious answer. Full syntax compatibility
does have some value, after all. And beyond that, the trick of dropping the
time offset only works if lack of zone specificity is the only reason why the
value can't be treated as a timestamp. If there are going to be other reasons
why one of these values doesn't specify a point in time it significantly
diminishes the value of the approach.

> > > to the idea of the first part not being exactly an RFC3339 production - so I'm
> > > proposing a format which always contains an RFC3339 component and yet is
> > > reliably convertable.

> > Do we know why there was such strong pushback?  What were the underlying

The original pushback was against specifying something with the intention, of
obsoleting RFC 3339 with an extended syntax. (The original proposal was, in
fact, a direct revision of RFC 3339.)

> (2) almost, but not entirely unlike RFC 3339.

Agreed.

> wanted SEDATE to be (a) only.

FWIW, my pushback was almost exactly the opposite of this: I never had a 
problem with work on timey-wimey non-timestamp things. My concern was with
possible impact on existing use of the timestamp format.

> (b) are almost timestamps, but reference a timezone with the intent to update
> the actual time stamp based on changes to the timezone;

> (c) are not timestamps at all, but user-visible indications of intent that
> only make sense in the context of a specific user (“floating”).

But do they always float in the sense of the zone being the thing that's not
nailed down? 

And there's also (d):

(d) A timestamp annotated with information about how best to display it, e.g.,
    using an alternate calendar.

> (b) is still mostly deterministic (i.e., there are usually ways to find out
> how a timezone changes, so after a little period of confusion people again
> agree what timestamp is/was meant).

Agreed.

> It should most definitely not look like RFC 3339 (e.g., by leaving out offset

OK... so if we accept this reasoning, there needs to be an explanation of
why the samething doesn't apply to the "almost timestamps" of (b).

> By the way, the military character for “local time” is “J" (where
> “Z” is world time), so the natural way to say

> Not RFC 3339, and clearly saying that this is not a timestamp unless context

FWIW I slightly prefer the J approach, but let's not dive into syntax details
until there's agreement on the more abstract points.

				Ned

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 9 Nov 2021 09:59:17 +0900

Hello Shane, others,

> zone "win" in the case of a conflict?

To be more precise, with (1), are you referring to the 'doubled' one 
hour when switching back from summer time to normal time that results 
because clocks have to be switched back by one hour? So as a specific 
example, this would allow to distinguish

2021-10-31T02:30:00+02:00[Europe/Zurich] (before setting clocks back)
and
2021-10-31T02:30:00+01:00[Europe/Zurich] (after setting clocks back)
which both actually existed. In this case, wouldn't it be more 
straightforward to just denote these two instants in time as
2021-10-31T02:30:00+02:00 and 2021-10-31T02:30:00+01:00 ?

Also, with (2), are you referring to cases where the rules suddenly 
change on short notice? In that case, is the purpose of having both 
pieces of information to distinguish between "this is according to the 
old rules, before the sudden rule change" and "this is according to the 
new rules" ? Again, wouldn't it be easier to just have the actual 
information?

> 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=prefer]

Why give two (possibly conflicting) pieces of information to then say 
which one actually counts? Isn't it much easier to just give the 
information you want to be used, and leave the other part out?
So insteaf of

 > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=ignore]
just write 2022-11-26T20:00:00[Australia/Melbourne],
and instead of
 > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=prefer]
just write 2022-11-26T20:00:00+11:00 ?

Regards,   Martin.

---

From: Justin Grant <[email-masked]>
Date: Mon, 8 Nov 2021 18:07:57 -0800

I see two common themes on the thread above: A) need to carefully name and
define use cases we're concerned about; B) carefully document objections to
previous proposals to address those use cases. Here's an attempt to cover
those two things by summarizing below what I heard above. Let me know what
you think.

*Name and define use cases we're concerned about (names are placeholders)*

   - *"Timestamp"* - What RFC 3339 specifies. It's an unambiguous
   time-from-epoch numeric value. The offset must be included, either a Z or a
   numeric offset from UTC.
   - *"DateTime"* - a "floating" date/time string that does not include any
   reference to a time zone or offset. This is the same data model (with
   different syntax) as is used by Form #1 of the data model for calendar
   meetings in RFC 5545 3.3.5
   <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.
   - *"Z Timestamp"* - A timestamp string that makes no assertions about
   the local time when the timestamp when it was captured. This is the same
   data model as Form #2 of calendar meetings defined in RFC 5545 3.3.5
   <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.
   - *"Numeric Offset Timestamp"* - A timestamp string that combines a
   date/time string with a numeric offset. Unlike Z Timestamps, this format
   allows recording the local time when the timestamp was captured.
   - *"Timestamp + Extensions"* - A timestamp with optional extensions
   that may describe its time zone as well as other extensions like
   calendars.  Note: it seems like calendars don't cause any problems in this
   thread, so I'll ignore them in the bullet points below.
   - *"DateTime + Offset + Timezone"* ( *"DTOTZ"* for short?) - A string
   that combines the syntax of a Numeric Offset Timestamp with a time zone
   extension. The timestamp portion of the string may or may not match the
   semantics of RFC 3339 depending on an obscure corner case: if the timestamp
   is in the future or the recent past, then it's rare but possible for the
   offset to change so that evaluating the same timestamp in that timezone
   will yield a different local date/time. In those cases, the receiver must
   have a way to resolve the conflict, either by specifying which one "wins"
   or specifying "mutual consent of communicating parties".  I believe this is
   case (b) in the thread above.  This format has not been standardized, but
   it's been used for many years by Java and other libraries and Temporal is
   planning to use it too.
   - *"DateTime + Timezone"* (aka *"DTT"*?) - a DateTime combined with the
   time zone used to convert that floating DateTime into a timestamp. No
   offset is stored, so the Timestamp must be calculated by the receiver.
   Note that during backwards DST transitions, the same DateTime will repeat
   twice. So there must be a way to resolve the ambiguity.  This case
   corresponds to the data model of Form #3 of RFC 5545 3.3.5
   <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.  I
   believe this is case (b) in the thread above. Temporal also supports this
   format.  This is perhaps the most important format for calendaring apps
   because normal end-users create events in local time and a time zone;
   calendar UIs almost never expose technical details like offsets or repeated
   hours during a DST transition.

Did I get the cases right?  Did I miss anything important?

*2) Objections/concerns/questions to address those use cases.*

I'll do my best to document what I've heard above. I suspect this list may
be incomplete.

   1. *Should this RFC allow strings that match RFC 3339 syntax without
   matching RFC 3339 semantics?*  Can existing RFC 3339-compliant code
   strip any annotations and use the resulting string as a timestamp?  Or will
   old code need to be re-tooled to account for new behavior? From reading the
   comments above, this seems to be the primary objection from multiple
   commenters. Correct?
   2. *Is a DTOTZ a timestamp according to RFC 3339?*  Calling this an
   "almost timestamp" above may be overstating the deviation, because this
   string *does* represent an unambiguous instant on the timeline when the
   timestamp was captured. An RFC 3339-compliant application that doesn't know
   about time zones can safely use this format. So I think the answer to this
   concern is "yes". Anyone disagree?
   3. *What should receivers do if offset and time zone conflict in a
   DTOTZ?* The extra metadata added by the time zone exposes potential
   ambiguity that the receiver will have to deal with in the (rare) case
   where time zone rules have changed between when the timestamp was stored
   and when it is being interpreted, or if the communicating parties are using
   a different TZDB version. What should the receiver do if there's a
   conflict? Should the timestamp win, yielding a different local time? (This
   breaks calendar applications, FWIW.) Or should the local time win, yielding
   a different timestamp than receivers that only know about RFC 3339?  Or
   should the RFC punt on this case and leave it up to the communicating
   parties to work it out, as ISO 8601 does in a lot of similar cases like the
   number of decimal digits allowed?  Temporal is in the "leave it up to
   communicating parties" camp, but IMHO the only really bad outcome would be
   standardizing the "DateTime MUST win" behavior because that would force
   receivers to behave differently from RFC 3339 which seems undesirable and
   would probably trigger objection (1) above.
   4. *How should senders communicate to receivers that they want the
   Timestamp or the DateTime to "win" if there's a conflict?* To avoid the
   "conflict" case above, I've heard the following options above:
      - a) Senders should use a Z Timestamp + TimeZone string if they want
      the Timestamp to win, and send a DTT if they want the DateTime to win
      - b) Senders can add another extension for this purpose, e.g.
      [offset=use] or [offset=ignore].
      - c) Overload the time zone annotation, e.g. [tz=Asia/Tokyo] means
      "DateTime wins" but  [Asia/Tokyo] means "Timestamp wins"
      - d) N/A, because our answer to (3) will preclude the possibility of
      conflicts by specifying either the timestamp or the DateTime will always
      win.
      - Are there any other options?
   5. *What should be the syntax of a DTT string? * I've heard the
   following suggestions above:
      - a) Omit the offset. This is what Temporal prefers, BTW.
      - b) Use a J offset.
      - c) Use a special time zone annotation, e.g. [tz=Asia/Tokyo] as
      opposed to [Asia/Tokyo], that means to interpret the "timestamp"
      string not as a timestamp but instead using some other
semantics.  My sense
      from reading the comments above is that this option would trigger concern
      (1) above so would elicit a lot of opposition.
      - Are there other options?
   6. *Even if all the concerns above are addressed, should DTT be
   specified at all?* DTT is probably the primary data model for calendar
   meetings and other end-user UI "time in my time zone" cases. Furthermore,
   DTT strings are clearly *not* Timestamps because they lack an offset, so
   there should be no backwards-compatibility issues.  If there are no
   backwards-compatibility issues, then are there *other* objections to
   specifying DTT strings?

Did I miss any other objections? Please feel free to add others or correct
me if I got something wrong above. Obviously I have opinions about better
vs worse answers to the questions above, but at this point I'm mostly
concerned with making sure we understand the issues involved and where
various folks stand on those issues. Thanks!

Cheers,
Justin

On Mon, Nov 8, 2021 at 4:59 PM Martin J. Dürst <[email-masked]>
wrote:

> offset

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 09 Nov 2021 22:01:15 +1100

On Tue, Nov 9, 2021, at 13:07, Justin Grant wrote:
> I see two common themes on the thread above: A) need to carefully name and define use cases we're concerned about; B) carefully document objections to previous proposals to address those use cases. Here's an attempt to cover those two things by summarizing below what I heard above. Let me know what you think.
> 
>  * *"Timestamp"* - What RFC 3339 specifies. It's an unambiguous time-from-epoch numeric value. The offset must be included, either a Z or a numeric offset from UTC.
>  * *"DateTime"* - a "floating" date/time string that does not include any reference to a time zone or offset. This is the same data model (with different syntax) as is used by Form #1 of the data model for calendar meetings in RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.
>  * *"Z Timestamp"* - A timestamp string that makes no assertions about the local time when the timestamp when it was captured. This is the same data model as Form #2 of calendar meetings defined in RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.

When naming I'd probably spell this out as 'Zulu Timestamp'.

>  * *"Numeric Offset Timestamp"* - A timestamp string that combines a date/time string with a numeric offset. Unlike Z Timestamps, this format allows recording the local time when the timestamp was captured.
>  * *"Timestamp + Extensions"* - A timestamp with optional extensions that may describe its time zone as well as other extensions like calendars.  Note: it seems like calendars don't cause any problems in this thread, so I'll ignore them in the bullet points below.
>  * *"DateTime + Offset + Timezone"* ( *"DTOTZ"* for short?) - A string that combines the syntax of a Numeric Offset Timestamp with a time zone extension. The timestamp portion of the string may or may not match the semantics of RFC 3339 depending on an obscure corner case: if the timestamp is in the future or the recent past, then it's rare but possible for the offset to change so that evaluating the same timestamp in that timezone will yield a different local date/time. In those cases, the receiver must have a way to resolve the conflict, either by specifying which one "wins" or specifying "mutual consent of communicating parties".  I believe this is case (b) in the thread above.  This format has not been standardized, but it's been used for many years by Java and other libraries and Temporal is planning to use it too.

Why not just spell this as "Timestamp + Timezone" or "Zoned Timestamp"

>  * *"DateTime + Timezone"* (aka *"DTT"*?) - a DateTime combined with the time zone used to convert that floating DateTime into a timestamp. No offset is stored, so the Timestamp must be calculated by the receiver.  Note that during backwards DST transitions, the same DateTime will repeat twice. So there must be a way to resolve the ambiguity.  This case corresponds to the data model of Form #3 of RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.  I believe this is case (b) in the thread above. Temporal also supports this format.  This is perhaps the most important format for calendaring apps because normal end-users create events in local time and a time zone; calendar UIs almost never expose technical details like offsets or repeated hours during a DST transition.

And of course "Zoned Datetime".

> I'll do my best to document what I've heard above. I suspect this list may be incomplete.
>  1. *Should this RFC allow strings that match RFC 3339 syntax without matching RFC 3339 semantics?*  Can existing RFC 3339-compliant code strip any annotations and use the resulting string as a timestamp?  Or will old code need to be re-tooled to account for new behavior? From reading the comments above, this seems to be the primary objection from multiple commenters. Correct?
>  2. *Is a DTOTZ a timestamp according to RFC 3339?*  Calling this an "almost timestamp" above may be overstating the deviation, because this string *does* represent an unambiguous instant on the timeline when the timestamp was captured. An RFC 3339-compliant application that doesn't know about time zones can safely use this format. So I think the answer to this concern is "yes". Anyone disagree?
>  3. *What should receivers do if offset and time zone conflict in a DTOTZ?* The extra metadata added by the time zone exposes potential ambiguity that the receiver will have to deal with in the (rare) case where time zone rules have changed between when the timestamp was stored and when it is being interpreted, or if the communicating parties are using a different TZDB version. What should the receiver do if there's a conflict? Should the timestamp win, yielding a different local time? (This breaks calendar applications, FWIW.) Or should the local time win, yielding a different timestamp than receivers that only know about RFC 3339?  Or should the RFC punt on this case and leave it up to the communicating parties to work it out, as ISO 8601 does in a lot of similar cases like the number of decimal digits allowed?  Temporal is in the "leave it up to communicating parties" camp, but IMHO the only really bad outcome would be standardizing the "DateTime MUST win" behavior because that would force receivers to behave differently from RFC 3339 which seems undesirable and would probably trigger objection (1) above.

This is the case for which I want the creator of the item to set a preference.  I don't particularly care WHICH syntax so long as it is:
* unambiguous for a machine to parse
* easy for a human to understand
* hard to get wrong (fewest possible invalid things that look correct, fewest weird corner cases for generating software to deal with)

>  1. *How should senders communicate to receivers that they want the Timestamp or the DateTime to "win" if there's a conflict?* To avoid the "conflict" case above, I've heard the following options above:
>    * a) Senders should use a Z Timestamp + TimeZone string if they want the Timestamp to win, and send a DTT if they want the DateTime to win

I feel like this fails the "easy to get right, hard to get wrong" thing.  People don't treat 'DatetimeZ' as being different from 'Datetime+00:00' - and even more importantly, libraries don't.  So you'll run into the problem that data gets lost when using what would otherwise have been sensible toolchains.

>    * b) Senders can add another extension for this purpose, e.g. [offset=use] or [offset=ignore].
>    * c) Overload the time zone annotation, e.g. [tz=Asia/Tokyo] means "DateTime wins" but  [Asia/Tokyo] means "Timestamp wins"
>    * d) N/A, because our answer to (3) will preclude the possibility of conflicts by specifying either the timestamp or the DateTime will always win.
>    * Are there any other options?
>  1. *What should be the syntax of a DTT string? * I've heard the following suggestions above:
>    * a) Omit the offset. This is what Temporal prefers, BTW.

It's what I prefer too, but it does meant that the 'Datetime' construct is NOT an RFC3339 production.  On the plus side, it is unambigous, easy for humans to read, and hard to get wrong.

>    * b) Use a J offset. 
>    * c) Use a special time zone annotation, e.g. [tz=Asia/Tokyo] as opposed to [Asia/Tokyo], that means to interpret the "timestamp" string not as a timestamp but instead using some other semantics.  My sense from reading the comments above is that this option would trigger concern (1) above so would elicit a lot of opposition. 
>    * Are there other options?

BUT - I do also like the idea of having an offset hint even if it's a "Zoned Datetime" because it helps debug what the senders belief was, and it also nicely disambiguates the daylight savings repeat.

>  1. *Even if all the concerns above are addressed, should DTT be specified at all?* DTT is probably the primary data model for calendar meetings and other end-user UI "time in my time zone" cases. Furthermore, DTT strings are clearly *not* Timestamps because they lack an offset, so there should be no backwards-compatibility issues.  If there are no backwards-compatibility issues, then are there *other* objections to specifying DTT strings?
> Did I miss any other objections? Please feel free to add others or correct me if I got something wrong above. Obviously I have opinions about better vs worse answers to the questions above, but at this point I'm mostly concerned with making sure we understand the issues involved and where various folks stand on those issues. Thanks!

I think it should be.  I'm happy with doing a separate document for it, but I wouldn't want to repeat all the work in this document, so we'd basically want to define all the extensions in a way that's easily referenced from a new document that defines naked 'Datetime' values to be used with the same extensions.

Bron.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2021 12:11:23 +0100

Standard mistake in developing text-based data formats(*):  
Discussing the syntax before discussing the data model.

(Yes, I threw “J” into the syntax mold, but just because that was missing from the syntax discussion.  
But I’d like the meeting in 2½ hours to really focus on semantics (**).
Please see my — updated — slides [1] for how I propose to do this.)

Grüße, Carsten

[1]: https://datatracker.ietf.org/meeting/112/materials/slides-112-sedate-sedate-discussion-slides-carsten-01
(If that gives you a 404, the updated slides aren’t in the datatracker yet. -00 is the old version.)

(*) The fun part is where people are throwing example texts at each other, assuming that the other people read the same semantics out of the text example — which of course they don’t, and confusion ensues.  With luck, the resulting syntax will be beautiful, and the semantics contorted and ambiguous.

(**) With the small monkey-wrench that we need to be compatible in certain ways to RFC3339 syntax — but we’ll come to that.