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