# SEDATE Notes ## Intro and Note-Well Chairs reminded all of the Notewell, and the process for using the meetecho lite tool via QR code or datatracker link. ### ISO Liaison ISO has a formal process. The IAB have proposed a candidate, and ISO are meeting next week at which time they should approve the candidate if they passed the checks, expect an announcement next week. # DRAFT * 9 issues open in Github * -03 [ Get rid of namespaces ] * -04 [ Support offset timeones as in Java; Discuss meaning of named timezones ] ## Behaviour for conflicts * Ujjwal: my understanding is that current draft says if there's a mismatch between offset and TimeZone name, the offset wins. * Carsten: there's no answer in the text. It's application dependent. So you need to ask the application what the outcome should be. * Ujjwal: in the case where the application can't ask. For Temporal, the programmer can be required to choose behaviour. My intention is that the offset works. The timezone name can be ignored if not needed. * Suggest that if this group agrees, trusting the offset in case of conflict be the default behaviour if no way to check. * Means RFC3339 implementations can easily support this format by ignoring everything after the current format. * Mike Douglass: offset tells you what you believe the offset to be at the time the timestamp was created. If it's no longer correct at the time it's used. * Carsten: there's an indication that there's a problem. It's not specified yet. * Applications may want to decide. * Mike: just want to write down exactly what should happen. At least alerts you to the fact that there's a problem. In calendaring, there's things you should do at that point (reschedule). * Neil: what you do with a conflict HAS to be appication specific. Which is different than "always trust offset" * Bron: yes, * Neil: intent - why put a timezone. * Ujjwal: disagree with Mike - that if there's a conflict then the offset is necessarily wrong. It could be either way. If set an international meeting, and the TZ rules change, still means that the meeting needs to happen at the same time. Of course, also the opposite case. * More about the case - daemon on a server somewhere, needs to make a decision about the timestamp. No way to get clarification. * Pete Resnick: disagree with Ujjwal and Carsten -> if you know you've scheduled a meeting that you know is always at offset+800. If the hint isn't providing anything that's useful for a conflict, you should leave out the hint. Saying it should be in a timezone that might change is not useful. * If you're adding the hint of a textual timezone, then your intention is that it's at the zone. * Carsten: when I'm scheduling * Pete: if you scheduled in Pacific Daylight time, what is your intent? Meaningful data or not? * Carsten: it's meaningful for the interface. Acting as if not a problem. * Pete: the system needs an explicit marker. Making it a guess is the worst possible choice. * Carsten: don't think it's possible for the system to resolve any nonsense that the politicians come up with. * Ken: agree with Pete. The issue we have is that we're extending 3339, so we can't strip off the numeric timezone, so we're stuck with this artifact. Need a marker of intent. Perhaps we can steal from RFC8536 (use -0000 as the offset to say "just a placeholder, use IANA timezone") * Mike: think people are saying what I was going to say - treat it as an indicator "this is what I thought". Localtime is what matters to people. * Can't just say it's going to be at this UTC. Comes down to need to reschedule * Ujjwal: to answer Pete - need zone name when reading schedule, if you only have an offset, when doing aritmetic you can't take timezone into account. * Issue with trust TZDB, you can't make sure everybody is on the same page. If I say we should trust TZ rules, and have a different version than another user, does it mean colleagues would be prompted with the wrong time? * Carsten: think we'll have to take to the list. Bron SUMMARY: has to be either explicit in the spec, or a marker. Pete: think that's close, the important bottom line is that you've got to decide what the markers mean. If you want a case where I'm giving you something, but I'm not sure what it means - there needs to be a default interpretation. If the system wants to express both a numeric offset and a timezone name, and I can't assess the creators intent, there must be a default interpretation. There's no point at which systems don't know the correct intent, and are picking two different outcomes. Carsten: first choice is RFC3339 timestamp, we're bound by RFC3339 for the default choice, which is often the wrong choice! ## X- We know people will do what they're told not to do, but this is the best we can? ## Do we have a way to say "MUST be understood" for extensions? Need a syntax - want people to reply to the issue. * Ujjwal: while it solves a lot of the problems, one of the goals was to allow implementations that follow defacto spec would keep working. * Carsten: damage doing this later would be worse than now. * Ujjwal: that's fair, not against it. Just pointing out drawbacks. * Pete: Trying to understand what it means to reject the date. In previous discussion, might interpret the date differently. If I get an event that has a critical thing I don't understand, what am I meant to do? * Bron: treat as malformed. * Carsten: strong incentive not to send such things. ## The name! Proposals? There were no proposals in the room. ## Extension format Carsten: Need at least one extension defined that people might want to use. Propose that we define something! Ujjwal: happy to do calendars, we need it for temporal. - will write a PR. ## ABNF Top down or bottom up. Maybe better to write top down, entry points not buried. # MILESTONES * Target June 2022. * Interim at end of May if needed. # ACTIONS: * Ujjwal to do PR for u-ca - calendar systems * Mailing list discussion about explicit marker for tz name vs offset * Mailing list discussion for naming bikeshed