Minutes IETF111: sedate
minutes-111-sedate-00

SEDATE Working Group - IETF 111

Tuesday, July 27, 2021 12:00-14:00 PDT (19:00-21:00 UTC)
Chairs: Bron Gondwana, Mark McFadden

Charter Review, Chairs, 15 min.

AOB, 5 min.
Notes
## draft-ryzokuken-datetime-extended-02

Ujjwal Sharma presenting

Neil Jenkins: is the ‘Z’ meant to be there? (in the example:
`2021-07-26T10:47:25Z[EUROPE/LONDON]`)

Ujjwal: yes, the instant is supposed to be there - it’s an exact time.

Neil: what does that mean if the time isn’t in the zone?

Pete Resnick: what if I put a timezone in there that’s in the instant time,
that has nothing to do with the named zone?

Ujjwal: that’s up to the implementation. It has two pieces of information, the
instant and the zone.  There’s no requirement that they match. In temporal it’s
valid by the protocol but not accepted by some implementations.

The instant itself doesn’t change, but you can’t process it.

Pete: Can always calculate universal time from the left hand side - the right
hand side says “what summer time rules, etc”

Ujjwal: an offset which doesn’t match the zone at all is probably a programmer
error, so the general case is to throw an error unless the programmer specifies
what to do in a mismatch. Another option is to downgrade the result to an
object that can be used for comparisons but not arithmetic.

Pete: should probably put on hold the idea of “implementation dependent or
rejected”, because what produces the time might be quite separate from the
locale process.

Ujjwal: I see what you mean -> can have a database which stores just the
timestamp part.

Pete: Suggest that a lot of this applicability/context is worth adding to the
document in some way. People will have lots of different uses of these things,
and it’s worth explaining in the document that you don’t want the RHS suffixes
if you’re using it just for a point in time.

Ujjwal: sounds like great advice, maybe we can add a use-cases section in the
document.

Keith Bare: appreciated the example usecases in the presentation, that wasn’t
clear in the document.

Keith: would you be allowed to have a date WITHOUT a timezone?

Ujjwal: that’s something that’s troubled the TC39 group quite a lot. On the one
hand, there’s important reasons to force people to have the offset so that the
instant itself doesn’t depend on the rest of the information. But have talked
to many people who work on calendars or things that deal with timescales, and
they are interested in floating times.

No we defer to RFC3339 for the LHS, so any other standard could add on the RHS
bit.

Temporal allows offset to be skipped in some cases - allows bare date.

Keith: timezone name is typically referring to an external system file (at
least in Unix) which might change, or that you might not have… if you’re
talking about something in local time in the future, if the zone file gets
updated you might not treat that date as the same instant if your file gets
updated.

Ujjwal: that’s just if you don’t include the offset right? That’s exactly why
we require the offset!

If we made this optional, we’d have to define what to do!

Neil Jenkins: including the offset doesn’t work for calendaring systems.
Daylight savings times change politically. You need to be able to give local
times. Understanding of temporal was that it also allows wallclock plus zone.

Ujjwal: in Temporal, this format is used for instants - a tuple of instant plus
timezone object. Neil: does it serialise to Z or +0000? Ujjwal: is it different?

Ujjwal: also -> what if it was a Japanese date, do you serialise that? Then the
parsing depends on the RHS. This is also relevant to the class of items that
require timescales. Propose that we should talk about this exact class of
use-cases in the working group for cases where the offset it not included.

Bron - definitely a work item.

Henk Birkholz: don’t really understand what problem has been solved. Whatever
is processing timezones needs to get updates - the code processing this data
needs to have the latest updates, so you don’t know for the future what the
rules will be when you do math on the date. Do you use geo location instead?
Just want to highlight that you’re adding a lot of complexity here!

Ujjwal: different sytems handle different ways.

Henk: but my clock has to update!

Ujjwal: that’s only relevant if your clock uses that system. You don’t need to
care about that value unless you are working with those values.

Henk: would be careful, mixing calendars which handle days with timescales
which measure seconds. It’s important to not mix up the idea of counting days
in calendars and representing time.

Ujjwal: that’s the point I’m trying to make! The set of values which should be
represented would be useful for some kinds of applications. The complexity
that’s added for an application is only relevant to which information you want
to consume. If you’re building an application which only cares about the
instant, you can ignore the other context. The idea is that you select what you
care about.

Henk: subjectively: when I write emails, if I orchestrate an event between
participants in different timezones, I write down the times for each person to
make it easier, and also give a + offset. They care about the offset, not the
zone name.

John Klensin: there’s a thread in the chat! The syntax here is easy. The use
cases get complicated - the more of them there are, the more complicated it
gets. Recommend that we spell out where it is and isn’t applicable. Or narrow
it down and say “it’s good for these listed things”. In danger of getting into
extreme handwaving.

Ujjwal: that’s perfectly reasonable, thanks! Either way we progress, we can
make it clear.

John: they aren’t implementation details, they’re principles, and they need to
be not handwaved!

Ujjwal: upside of things not being specified, any change would need an update
to the RFC, which is a long process! If there’s a strong case for either
direction.

John: we can created registries as well. This can have different meanings in
different contexts and we need to make that really clear.

Ujjwal: BCP47 (locales) is nice. Privacy issues around

====

Ujjwal: question about process. When progressing different proposals in TC39 ->
have a point where we say “consensus has been reached that this is a problem
that’s worth solving, but we agree that it’s worth being solved”.

Adopting document equals “agreeing that it’s a problem that needs to be
addressed”

Document adoption will be done on the mailing list. Also, we will put out a
call for volunteers to be co-authors. We talked about whether to use GitHum or
email as the supporting tool for workflow. No decision on that. Will take that
to the mailing list as well.

ACTION: Bron to make a call for adoption of draft-ryzokuken-datetime-extended

Reviewed the existing milestone. Will be adding a milestone for adopting the
document in August 2021. We will also leave the December milestone as it is for
the itme being. No comments from the floor on milestones.

There were no items raised in any other business and Bron closed the meeting at
about 75 minutes.

ACTION: Bron to update milestones for SEDATE working group