* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Sedate Status Pages

Serialising Extended Data About Times and Events (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2021-Jul-02 —  
Chairs
 
 


IETF-111 sedate minutes


Minutes

minutes-111-sedate-00 minutes



          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
          
          



Generated from PyHt script /wg/sedate/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -