From nobody Sat Aug 1 20:04:47 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCE3A09B0 for ; Sat, 1 Aug 2020 20:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdZ6xc1emjIU for ; Sat, 1 Aug 2020 20:04:44 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683173A090C for ; Sat, 1 Aug 2020 20:04:44 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id v22so14139522edy.0 for ; Sat, 01 Aug 2020 20:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zOiYrvsfhgi7JNZc1U7IT0xwC/x06GNdf72jiewpf/M=; b=ennt7U+YmSZjygnwWuEZ/gJzu3GNjZxNbb2sMOmMo1alPI+2q5npibshZMO4nIj9Yz B5Pt9h2BiI0vhEHaDpCEA8Ns5DJvK0GpGXYc8nNjvM5GhptjD2RFIB8ZJKnIV/R6VznS i0v/dPWQjDRk8272gI/BhecdgxKroxgUdILD00bJwV+Je2vRQwfpg0miX55Tggb/T1Om CsMhD+MUcaY84njdazmvWGIJ51AcQP6e8dR18WqmGt5uDenq8nHaCxN1NMG3M6oTEpEL IZP13B3vrxkLExGvjbu5tDz+wWNEmHxOlzDsJkEHwGW3GpGkS6g8gTuimZiCxYKSeCtq bTlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zOiYrvsfhgi7JNZc1U7IT0xwC/x06GNdf72jiewpf/M=; b=PtjJ+BQZuutdMZhsL3E166WyAlmQeFtyUzX6Y0Vn9n5ltzL3PslMm406iNPllU/bUp QkgCXOpElZPgJ/kllxtStflnL51g9aeJogBhZWNwnvU4l9bnKQEvHQ8PxeFMgBdxicsY jYLk4B6I5ZOOxTuA7xDiRldCUWzC5Ch8p2Em0qrwOdkxSH6nAOhldB7g6gTpRU1w5mjo CddE6uBm0bX1bOXtgOUxb6OUsPOIB1oL4DXNTlIEZQojwlxCE/lF35e9IHFI2hn7niEO VQed8Wy4/1yok//IzcJBJJ082h1dak+PUHpCjEnm6UyR1WgNtD6d7UjGwgq8x5y4LQQ+ hp2w== X-Gm-Message-State: AOAM5312tmzd/wvhS94Wnmcm7oKsVETvXoLA3UojXK3DIlK2IkSe22Pe zt/YIGJVV49uXOnEebZUCD+a25wmwxbeKDR3yoA00XCJ X-Google-Smtp-Source: ABdhPJwRb//6QxzWd2ANgoA2m6VUGtlYH8mPv1QFqXaFpFptfEc3cOze5czfvAz9R8S11rbnuTqfhb6rkFuTJADLTKA= X-Received: by 2002:a50:ef08:: with SMTP id m8mr3029944eds.339.1596337482542; Sat, 01 Aug 2020 20:04:42 -0700 (PDT) MIME-Version: 1.0 From: Justin Grant Date: Sat, 1 Aug 2020 20:04:31 -0700 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000096b1a905abdc4816" Archived-At: Subject: Re: [calsify] RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 03:04:47 -0000 --00000000000096b1a905abdc4816 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil - Daniel helped me get my calsify email subscription fixed, so I'm replying on the public list. Reading your response, I realize that I forgot to add one important piece of context: all my questions focus on a specific type (placeholder name is "LocalDateTime'-- see https://github.com/tc39/proposal-temporal/issues/700) that we're adding to Temporal which represents a specific UTC instant in a specific time zone. This is closest to "DATE-TIME - FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE" in RFC 5545, although there's a small difference in that Temporal's LocalDateTime type will know its UTC value and will derive the local date/time from the time zone and the UTC value. This was done so that this type could represent all real-world instants (other than leap seconds), including times during the "repeated hour" after a Fall DST transition. Temporal also has types that correspond to FORM #2: DATE WITH UTC TIME (called "Absolute" in Temporal) and FORM #1: DATE WITH LOCAL TIME (called "DateTime" in Temporal). Math with these types is straightforward because neither of them have any awareness of time zones or DST. The questions in https://github.com/tc39/proposal-temporal/issues/702 only relate to the LocalDateTime type where the time zone is known and DST transitions must be accounted for. > Q1. [...] If I'm understanding it correctly, I do not think your proposed alternative is acceptable because it applies the time component to the wall-clock time, which means that if you had an event with duration PT1H that started on a 1-hour DST-transition point it would be translated into an absolute duration of 0 hours or 2 hours, which is clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a duration of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berlin. However, those are the same time in UTC due to the DST transition, so the absolute duration becomes 0! Yep, to avoid that problem you can either add the time portion using exact time, or you can do the time-portion math with wall-clock time and then adjust the result for the difference in time zone offset. Either one works to adjust for the impact of the DST transition. The advantage of the latter approach is that if there's a DST disambiguation required, it happens at the endpoint rather than at the intermediate value. This used to be important because when I wrote that GitHub issue, LocalDateTime offered user-customizable disambiguation behavior in its arithmetic functions. Since then, we've decided to simply use the "use the earlier offset" disambiguation method that RFC 5545 uses, so Q1 is probably a non-issue now. It still matters when calculating differences between LocalDateTime values (Q4/Q5), though. > Q1. [...] I'm not sure why you think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where it happens? Here's an example: what should be the result of adding P1DT12H to 2020-03-07T02:30-08:00[America/Los_Angeles]. My understanding of RFC5545's algorithm is that we'd use the following steps: A) Add 1 calendar day. B) Add 12 exact hours (not clock hours) But the after step A, the local time is not valid because 2020-03-08T02:30 is in the middle of the hour skipped by a DST transition. My interpretation of RFC 5545 is that we'd interpret the invalid intermediate time by using the offset before the transition, so we'd end up with an intermediate value of 2020-03-08T03:30-07:00[America/Los_Angeles] and a final result of 2020-03-08T15:30-07:00[America/Los_Angeles]. Is this correct? > Q3. I don't think subtraction is well specified and probably wasn't deeply considered; it is basically only used for the offset of alerts before the start of the event and I think your proposal of subtracting absolute components first is very reasonable for the reason you gave. We should clarify this in the JSCalendar spec. Sounds great. We'll plan to continue using smallest-units-first order-of-operations for subtraction. > Q4. [...] Subtract hours/minutes first to get the same wall clock time, then calculate number of days difference to get a duration in weeks/days/hours/minutes/seconds. What should we do when the "same wall clock time" happens to be in the middle of an hour skipped by a Spring DST transition? See Q5 discussion below for more details. > Q5. I don't think I quite understand your question. You say you are "calculating differences between UTC values" but then the "difference ends inside a DST discontinuity" =E2=80=93 UTC doesn't have DST, so this doesn't= make sense. Could you please clarify? This is the inverse of Q1. In Q1 we add a Duration to a LocalDateTime and have to deal with a DST transition in the middle. Q5 is about calculating the Duration between two LocalDateTime values with a DST transition in the middle. My understanding of RFC 5545 is that there are two possible ways to calculate the Duration between two LocalDateTime values X and Y in the same time zone. Let's call them the "Addition Path" and "Subtraction Path". Addition Path A) Let D =3D Y - X ignoring any changes in time zone offset between X and= Y B) Truncate the time portion of D, leaving only a date-only duration C) Let I =3D X+D. If I is an invalid time (e.g. the hour skipped when DST starts) then resolve by using the earlier offset, which will yield a time later than the discontinuity. D) Let T =3D the exact clock time difference between I and Y. E) Merge N and T into the result Duration Subtraction Path A) Let D =3D Y - X ignoring any changes in time zone offset between X and= Y B) Truncate the time portion of D, leaving only a date-only duration C) Let I =3D Y-D. (Hence the name "Subtraction Path"). If I is an invalid time (e.g. the hour skipped when DST starts) then resolve by using the earlier offset, which will yield a time later than the discontinuity. D) Let T =3D the exact clock time difference between X and I. (The other path uses I and Y) E) Merge N and T into the result Duration Are both of these compliant with your understanding of RFC 5545? Is only one correct? Or is neither correct? One problem is that the Addition Path and the Subtraction Path can return different results when an endpoint is in the "repeated hour" after DST ends in the fall. For example, assume that X is 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the day DST ends). If we start from X, then we'd add one nominal day to get 2020-11-01T01:30-07:00[America/Los_Angeles] (the "first" 1:30AM), and then add one exact hour to get to the end. So the result is P1DT1H. But if we start from Y, then subtracting one nominal day from 2020-11-01T01:30-08:00[America/Los_Angeles] yields 2020-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So the result is P1D. Another problem is that the logic above can deliver unexpected results depending on the local time of the endpoints, even if neither of those endpoints are close to a DST transition. For example, using the "Addition Path" logic above, here's the durations that the following pairs of LocalDateTime values will return: - 2020-03-07T01:30-08:00[America/Los_Angeles] to 2020-03-08T13:30-07:00[America/Los_Angeles] =3D> P1D12H - 2020-03-07T02:30-08:00[America/Los_Angeles] to 2020-03-08T14:30-07:00[America/Los_Angeles] =3D> P1D11H (1 hour less because the intermediate time 2020-03-08T02:30 is resolved to 2020-03-08T03:30-07:00[America/Los_Angeles] before the exact time difference is calculated) - 2020-03-07T03:30-08:00[America/Los_Angeles] to 2020-03-08T15:30-07:00[America/Los_Angeles] =3D> P1D12H Users probably won't be surprised to see divergent results in cases where the endpoints are within an hour of a DST transition. But what's unexpected is the variation in results caused by the intermediate result landing on an invalid time, even though neither of the endpoints are very close to the transition. Does this clarify the problems we're trying to resolve with Q5? *From: * *Date: *Thursday, July 30, 2020 at 6:49 PM *To: * *Subject: *Re: RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group On Fri, 31 Jul 2020, at 05:10, Justin Grant wrote: Hi JSCalendar team =E2=80=93 I=E2=80=99m part of the TC39 working group tha= t=E2=80=99s working on the Temporal proposal which will be the future date/time API for JavaScript. We=E2=80=99re planning to= follow RFC 5545 for operations that add or subtract durations from date/time values. But we have some questions about how to interpret the iCalendar spec around edge cases when there=E2=80=99s a DST transition during the add= ed or subtracted duration. [...] Hi Justin, I'm happy to answer some questions; your link was to the GitHub project rather than a specific issue, but I'm presuming it's https://github.com/tc39/proposal-temporal/issues/702 that you were referring to. I've copied this to the calsify (Calext WG) list , but encourage people to reply-all as you have had difficulty joining it. In answer to the questions in that issue, my understanding is: Q1. As specified in RFC5545 (and JSCalendar): - A duration does not have a time zone associated with it. It is just an abstract number of weeks/days/hours etc. - If you want to determine how long in absolute terms a duration with days/weeks is, this question only makes sense when you have a start date-time to apply it to. - A duration may be added or subtracted from a date-time. If the date-time does not have an associated time zone then this is very easy (it's just like UTC: 1 day is always exactly 24h). - Otherwise, as per the spec, you would add the weeks/days first to the calendar day/month/year. If the result is an ambiguous time due to DST, = you resolve at this point. Then you add the absolute hours/minutes/seconds e= tc. =E2=80=93 this cannot result in another ambiguity. There is only ambigui= ty mapping from TZ -> UTC, not UTC -> TZ. I think your implementation in (1) seems similar to this, but I have not looked at the source closely to confirm. I'm not sure why you think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where it happens? You just add the duration to the date-time and get a result. If I'm understanding it correctly, I do not think your proposed alternative is acceptable because it applies the time component to the wall-clock time, which means that if you had an event with duration PT1H that started on a 1-hour DST-transition point it would be translated into an absolute duration of 0 hours or 2 hours, which is clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a duration of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berlin. However, those are the same time in UTC due to the DST transition, so the absolute duration becomes 0! Q2. I don't think this issue arises when following the RFC5545 semantics above. Q3. I don't think subtraction is well specified and probably wasn't deeply considered; it is basically only used for the offset of alerts before the start of the event and I think your proposal of subtracting absolute components first is very reasonable for the reason you gave. We should clarify this in the JSCalendar spec. Q4. This is really an implementation question. The result is clearly only correct if you can add it to the start date and get back the end date again with the already defined semantics. You can either: - Just find the difference in absolute time and represent this as a duration in hours/minutes/seconds. - Subtract hours/minutes first to get the same wall clock time, then calculate number of days difference to get a duration in weeks/days/hours/minutes/seconds. Q5. I don't think I quite understand your question. You say you are "calculating differences between UTC values" but then the "difference ends inside a DST discontinuity" =E2=80=93 UTC doesn't have DST, so this doesn't= make sense. Could you please clarify? Cheers, Neil. --00000000000096b1a905abdc4816 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil - Daniel helped me get my calsify email subscripti= on fixed, so I'm replying on the public list.

Readin= g your response, I realize that I forgot to add one important piece of cont= ext: all my questions focus on a specific type (placeholder name is "L= ocalDateTime'-- see https://github.com/tc39/proposal-temporal/issues/700) tha= t we're adding to Temporal which represents a specific UTC instant in = a specific time zone.=C2=A0 This is closest to "DATE-TIME -=C2=A0FORM #3: DATE WITH LOCAL TI= ME AND TIME ZONE REFERENCE"=C2=A0in RFC 5545, although there= 9;s a small difference in that Temporal's=C2=A0LocalDateTime type will = know its=C2=A0UTC value and will derive the local date/time from the time z= one and the UTC value.=C2=A0 This was done so that this type could represen= t all real-world instants (other than leap seconds), including times during= the "repeated hour" after a Fall DST transition.

<= /div>
Temporal also has types that correspond to=C2=A0FORM #2: DATE WITH UTC TIME (called &qu= ot;Absolute" in Temporal) and=C2=A0FORM #1: DATE WITH LOCAL TIME (called "DateTi= me" in Temporal). Math with these types is straightforward because nei= ther of them have any awareness of time zones or DST.=C2=A0

The questions in=C2= =A0= https://github.com/tc39/proposal-temporal/issues/702=C2=A0only relate t= o the LocalDateTime type where=C2=A0the time zone is known and DST transitions must be accounted = for.
=
= > Q1. [...]=C2=A0If I'm understanding it correctly, I do not think your proposed alternative is acceptable because i= t applies the time component to the wall-clock time, which means that if you = had an event with duration PT1H that started on a 1-hour DST-transition point i= t would be translated into an absolute duration of 0 hours or 2 hours, which = is clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a duration of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berlin. However, those ar= e the same time in UTC due to the DST transition, so the absolute duration becomes 0!<= /span>

Yep, to avoid that problem you can either add t= he time portion using exact time, or you can do the time-portion math with = wall-clock time and then adjust the result for the difference in time zone = offset. Either one works to adjust for the impact of the DST transition. Th= e advantage of the latter approach is that if there's a DST disambiguat= ion required, it happens at the endpoint rather than at the intermediate va= lue. This used to be important because when I wrote that GitHub issue, Loca= lDateTime offered user-customizable disambiguation behavior in its arithmet= ic functions. Since then, we've decided to simply use the "use the= earlier offset" disambiguation method that RFC 5545 uses, so Q1 is pr= obably a non-issue now.=C2=A0 It still matters when calculating differences= between LocalDateTime values (Q4/Q5), though.

> Q1. [...]=C2=A0I'= m not sure why you think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where i= t happens?=C2=A0

Here's an example: what should be the result of adding P1DT12= H to=C2=A02020-03-07T02:30-08:00[America/Los_Angeles]. My und= erstanding of RFC5545's algorithm is that we'd use the following st= eps:
=C2=A0 A) Add 1 calendar day.
=C2=A0 B) Add 12 exa= ct hours (not clock hours)
But the after step A, the local time i= s not valid because=C2=A02020-03-08T02:30 is in the middle of the hour skip= ped by a DST transition. My interpretation of RFC 5545 is that we'd int= erpret the invalid intermediate time by using the offset before the transit= ion, so we'd end up with an intermediate value of 2020-03-08T03:30-07:0= 0[America/Los_Angeles] and a final result of 2020-03-08T15:30-07:00[America= /Los_Angeles].=C2=A0 Is this correct?=C2=A0=C2=A0

= > Q3. I don't think subtraction is well specified and probably wasn't deeply considered; it is basicall= y only used for the offset of alerts before the start of the event and I think you= r proposal of subtracting absolute components first is very reasonable for th= e reason you gave. We should clarify this in the JSCalendar spec.=C2=A0
=

=
Sounds great. We'll plan to continue using smallest-units-first or= der-of-operations for subtraction.=C2=A0

> Q4. = [...] Subtract hours/minutes first to get the same wall clock time, then calculate nu= mber of days difference to get a duration in weeks/days/hours/minutes/secon= ds.

What should we do when the "same wall clo= ck time" happens to be in the middle of an hour skipped by a Spring DS= T transition?=C2=A0 See Q5 discussion below for more details.
>=C2=A0Q5. I don't think I quite understand your question. You say you are "calculating differences bet= ween UTC values" but then the "difference ends inside a DST discontinuity" =E2=80=93 UTC doesn't have DST, so this doesn't= make sense. Could you please clarify?

This is the inverse of Q1. In = Q1 we add a Duration to a LocalDateTime and have to deal with a DST transit= ion in the middle. Q5 is about calculating the Duration between two LocalDa= teTime values with a DST transition in the middle. My understanding of RFC = 5545 is that there are two possible ways to calculate the Duration between = two LocalDateTime values X and Y in the same time zone. Let's call them= the "Addition Path" and "Subtraction Path".
=
Addition Path=C2=A0
=C2=A0 A) Let D =3D Y - X igno= ring any changes in time zone offset between X and Y
=C2=A0 B) Tr= uncate the time portion of D, leaving only a date-only duration
= =C2=A0 C) Let I =3D X+D. If I is an invalid time (e.g. the hour skipped whe= n DST starts) then resolve by using the earlier offset, which will yield a = time later than the discontinuity.
=C2=A0 D) Let T =3D the exact = clock time difference between I and Y.=C2=A0
=C2=A0 E) Merge N an= d T into the result Duration

Subtraction Path= =C2=A0
=C2=A0 A) Let D =3D Y - X ignoring any changes in time zon= e offset between X and Y
=C2=A0 B) Truncate the time portion of D= , leaving only a date-only duration
=C2=A0 C) Let I =3D Y-D. (Hen= ce the name "Subtraction Path"). If I is an invalid time (e.g. th= e hour skipped when DST starts) then resolve by using the earlier offset, w= hich will yield a time later than the discontinuity.
=C2=A0 D) Le= t T =3D the exact clock time difference between X and I. (The other path us= es I and Y)=C2=A0
=C2=A0 E) Merge N and T into the result Duratio= n

Are=C2=A0both of these complian= t with your understanding of RFC 5545?=C2=A0 Is only one correct?=C2=A0 Or = is neither correct?

One problem is that the Additi= on Path and the Subtraction Path can return different results when an endpo= int is in the "repeated hour" after DST ends in the fall. For exa= mple, assume that X is 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is= =C2=A02020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1= :30AM on the day DST ends).=C2=A0 If we start from X, then we'd add one= nominal day to get 2020-11-01T01:30-07:00[America/Los_Angeles] (the "= first" 1:30AM), and then add one exact hour to get to the end. So the = result is P1DT1H.=C2=A0 But if we start from Y, then subtracting one nomina= l day from=C2=A02020-11-01T01:30-08:00[America/Los_Angeles] yields 2020-10-= 31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So the res= ult is=C2=A0P1D.

Another problem is that the = logic above can deliver unexpected results depending on the local time of t= he endpoints, even if neither of those endpoints are close to a DST transit= ion.=C2=A0 For example, using the "Addition Path" logic above, he= re's the durations that the following pairs of LocalDateTime values wil= l return:=C2=A0
  • 2020-03-07T01:30-08:00[America/Los_Angele= s] to=C2=A02020-03-08T13:30-07:00[America/Los_Angeles] =3D> P1D12H
  • 2020-03-07T02:30-08:00[America/Los_Angeles] to=C2=A02020-03-08T14:30= -07:00[America/Los_Angeles] =3D> P1D11H (1 hour less because the interme= diate time=C2=A02020-03-08T02:30 is resolved to=C2=A02020-03-08T03:30-07:00= [America/Los_Angeles] before the exact time difference is calculated)
  • 2020-03-07T03:30-08:00[America/Los_Angeles] to=C2=A02020-03-08T15:30= -07:00[America/Los_Angeles] =3D> P1D12H
Users probably won't be surprised to see divergent results in = cases where the endpoints are within an hour of a DST transition. But what&= #39;s unexpected is the variation in results caused by the intermediate res= ult landing on an invalid time,=C2=A0even though neither of the endpoints a= re very close to the transition.

Does this clarify= the problems=C2=A0we're=C2=A0trying to resolve with Q5?

=

From: <snip>

Date: Thursday, July 30, 2020 at 6:49 PM
To: <snip>

Subject: Re: RFC 5545/JSCalendar questions= from ECMAScript TC39 "Temporal" working group

On Fri, 31 Jul 2020, at 05:10, Justin Grant wrote:

Hi JSCalendar team =E2=80=93 I=E2=80=99m part of the TC39 working group that=E2=80=99s wo= rking on the Temporal proposal which will be the future date/time API for JavaScript.=C2=A0 We=E2= =80=99re planning to follow RFC 5545 for operations that add or subtract durations f= rom date/time values.=C2=A0 But we have some questions about how to interpret t= he iCalendar spec around edge cases when there=E2=80=99s a DST transition duri= ng the added or subtracted duration.


[...]


Hi Justin,

=C2=A0

I'm happy to answer some questions; your link was to the GitHub project rather than a specific issue= , but I'm presuming it's https://github.com/tc39/proposal-= temporal/issues/702 that you were referring to.

=C2=A0

I've copied this to the calsify (Calext WG) list, but encourage people to reply-all as you have had difficulty joining it.

=C2=A0

In answer to the questions in that issue, my understanding is:

=C2=A0

Q1. As specified in RFC5545 (and JSCalendar):

  • A duration does not have a time zone associated with it. It is just an abstract number of weeks/days/hours etc.
  • If you want to determine how long in absolute terms a duration with days/weeks is, this question only makes sense when you have a start date-time to apply it to.
  • A duration may be added or subtracted from a date-time. If the date-time does not have an associated time zone then this is very easy (it's= just like UTC: 1 day is always exactly 24h).
  • Otherwise, as per the spec, you would add the weeks/days first to the calendar day/month/year. If the result is an ambiguous time due to DST, you res= olve at this point. Then you add the absolute hours/minutes/seconds etc. = =E2=80=93 this cannot result in another ambiguity. There is only ambiguity mapping fr= om TZ -> UTC, not UTC -> TZ.

=C2=A0

I think your implementation in (1) seems similar to this, but I have not looked at the source closely t= o confirm. I'm not sure why you think the disambiguation in the middle is= going to be problematic for users; surely they generally won't notice where i= t happens? You just add the duration to the date-time and get a result.

=C2=A0

If I'm understanding it correctly, I do not think your proposed alternative is acceptable because i= t applies the time component to the wall-clock time, which means that if you = had an event with duration PT1H that started on a 1-hour DST-transition point i= t would be translated into an absolute duration of 0 hours or 2 hours, which = is clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a duration of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berlin. However, those ar= e the same time in UTC due to the DST transition, so the absolute duration becomes 0!<= /span>

=C2=A0

Q2. I don't think this issue arises when following the RFC5545 semantics above.

=C2=A0

Q3. I don't think subtraction is well specified and probably wasn't deeply considered; it is basicall= y only used for the offset of alerts before the start of the event and I think you= r proposal of subtracting absolute components first is very reasonable for th= e reason you gave. We should clarify this in the JSCalendar spec.

=C2=A0

Q4. This is really an implementation question. The result is clearly only correct if you can add = it to the start date and get back the end date again with the already defined semantics. You can either:

  • Just find the difference in absolute time and represent this as a duration = in hours/minutes/seconds.
  • Subtract hours/minutes first to get the same wall clock time, then calculate nu= mber of days difference to get a duration in weeks/days/hours/minutes/secon= ds.

=C2=A0

Q5. I don't think I quite understand your question. You say you are "calculating differences bet= ween UTC values" but then the "difference ends inside a DST discontinuity" =E2=80=93 UTC doesn't have DST, so this doesn't= make sense. Could you please clarify?

=C2=A0

Cheers,

Neil.


--00000000000096b1a905abdc4816-- From nobody Sat Aug 1 21:20:03 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D512C3A0BF6 for ; Sat, 1 Aug 2020 21:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dykxgwFh0Bc for ; Sat, 1 Aug 2020 21:20:01 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19B93A0BF2 for ; Sat, 1 Aug 2020 21:20:00 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id v22so20100477qtq.8 for ; Sat, 01 Aug 2020 21:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=B+Dj6wtwZfc7T9LOGnCUCqQpx+mChKtmWkQvOVlN4aI=; b=nNH373dsJFbyZJPBdFOL1e6cvWc9iyAL36oCT4zb2Pn49GEToLspM6GjdiQZSmVxBg s1GEJWOCKDvhJ6ieLSbyrD44cnRxUOA+dXpk/vVhS6YWgNducdp4XvbYws7hStU87vh8 PcMEuKGdcB79ROVK3UNG7+OHhqYyLMtnwdNZPc5rSSH8Uwknv7qwWmL03ppSNd3oCjdB WJ6MbQ7ZdK3FJ92Mfp1N9mzBA/KVb4SFMhjHLQGfVWW4LtGbJDtLQJzgDPKv0aRnvOw/ PtwCvewoKObO4yTtS2SfxVktA/BqRuau7AR8uV59X4A54pJajD6l5itHTC9Gt0sdABLD yPDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=B+Dj6wtwZfc7T9LOGnCUCqQpx+mChKtmWkQvOVlN4aI=; b=arXnmv84F5SxqCeo43v06EtTEA79veNbASvwh09y/Hn+oQdqB9rjUz+hpQg+Dcyf/x LwCQ7y1003UrAPGDLMu/R7xKPqqYDG4oTiKBmcdSM3VQYZbsuHhGgAmpmcbEZeKNrGO/ /NlHmd+ia6HOocqbfvku5BphHSTRPxWNEXLBziibJ3FJaRt5z0GJDz3OFEslxsDuwMdo sudVNwZR/ATG6ee6zEPGwEsivU4j2XAFkXGEKlGn0A6k4v2iZ7pF3ipYXi6MRiP/wY8F X0/XOxoniRcCynu3sX7x95YygO5kAXLMMRfxi6NHxEbcpMU7qRdhkZ+xOuZMmpjFebnN 0bPA== X-Gm-Message-State: AOAM533pvB9UdbexBsBmSpOdURSSVIdED2dZd6OrUouNo1AM1yhc/fe2 UqoRVRlZJJLPM2moI4SPe38xHkeX+Vw= X-Google-Smtp-Source: ABdhPJyf8TRatHXvyBmwKTlNt9OCuGunaPYYOnWS3Wm7BZCfQ4xpRFLckghdzldHTX9NriobAr73aw== X-Received: by 2002:aed:3123:: with SMTP id 32mr396673qtg.147.1596341999625; Sat, 01 Aug 2020 21:19:59 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r6sm15160016qtt.81.2020.08.01.21.19.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Aug 2020 21:19:59 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Sun, 2 Aug 2020 00:19:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar: Vendor specific names and overrides X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 04:20:02 -0000 Doesn't the construct "example.com/customprop" make it difficult to process overrides? {...   "example.com/customprop": 12345 ...   "recurrenceOverrides": {     "2018-01-05T14:00:00": {       "example.com/customprop": 56789    }, ...} Where's the "example.com" property? A different delimiter perhaps? From nobody Sun Aug 2 11:17:07 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7E23A0A90 for ; Sun, 2 Aug 2020 11:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWoeihFExIVg for ; Sun, 2 Aug 2020 11:17:04 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38523A0A8E for ; Sun, 2 Aug 2020 11:17:03 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id j187so33327642qke.11 for ; Sun, 02 Aug 2020 11:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=yPj49DnNVxkT98gkI1iyjWvzURgKrBajMqEC7SzGfGw=; b=LRAXFPjjvyDTcgC3Efacp5cFEmW6UFgUci5PdfYs8/oDhgbwamb0R93cNFKlFt16FI LWrbPD+oe0JtbFZS/byO16B/jSAZ+7lGpbC57yBO9HntSi80nO7KoyFOP3tyfPChS7nB gJQSnalGqIlyhgO+IN1JcRVoySO6qzywMjF5ozwdjezRtM+r4+46znO0JskNkZI+2sOO K5aGMhhHQ3ypOwD8y7vWag8nZTGDKfz2ORM+nGB27m6yYxIaXNZO2jMyvBT4XT+o1THh QnmC191pXN7B0l9WCYdYYU019nufE97Yp3AH1prHGKr9Dvj03WXL8f3tW7VGCdxuMFVr Kfhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=yPj49DnNVxkT98gkI1iyjWvzURgKrBajMqEC7SzGfGw=; b=GgVriBo1B5nCytfXKiO0mr+uSDsOoPwjlnFG8trXEujTNe7wQrtsAFc1u12Bd5u3A5 FYvuNnZSpS/UjKgXDlKoMS/a8NwmT/gpKMkeftlsG4EE9bXJYatVF9V4hl2jpQP85o2x useE4TdTUtmyvEhoeAm0sb+cyNkOkmg4DqVO9tDG9ndKPM3pyk52+BCkQmHydiqPysgH 0VcU4u4NRSkrOmImT/JO1SV4ExQNGumfuKd7l9r6wu2u3i7z6/gCRCWzkAaUa+ubXYuP ixwXtQYvWZEhDDADZwmMb3vx6Ovnaid8Y6oLCqF3r95NQsmigpia4VB1kU/LtL6h/+Lf JIPg== X-Gm-Message-State: AOAM5329gZUFe9oxlePxcRJAzbBq4Hht+5vNroV4FkIqK+Vm7/SB44T9 UfonZSwWHEE+oGTVo0WMSs9iGEPRi58= X-Google-Smtp-Source: ABdhPJxnIC+7c+SStpMQk083LqXe3+szk0FXxUyy9RGb7mb+1QAPDa19XXcInyibZh2B+V8iTGsFww== X-Received: by 2002:a05:620a:4006:: with SMTP id h6mr2671291qko.174.1596392220413; Sun, 02 Aug 2020 11:17:00 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id p123sm16057712qkd.26.2020.08.02.11.16.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Aug 2020 11:16:59 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Sun, 2 Aug 2020 14:16:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar - offsetTrigger - offset X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 18:17:05 -0000 The text for offset seems off... Defines the offset at which to trigger the alert relative to the time property defined in the relativeTo property of the alert. Negative durations signify alerts before the time property, positive durations signify alerts after. That's ok - Then it says: If the calendar object does not define a time zone, the user's default time zone SHOULD be used when determining the offset, if known. Otherwise, the time zone to use is implementation specific. Not sure what that means - is it supposed to be "when determining the trigger time"? In any case isn't the first part sufficient? Presumably the client has to deal with where the start/end lie already so it's just a matter of applying the offset. I think I'm saying the language about timezones belongs with start and end. From nobody Sun Aug 2 16:40:01 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E963A0DC0 for ; Sun, 2 Aug 2020 16:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=nqHb+zvw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OsU5nBkl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAaf8weWdqEy for ; Sun, 2 Aug 2020 16:39:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE593A0DBF for ; Sun, 2 Aug 2020 16:39:58 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EA7885C008E for ; Sun, 2 Aug 2020 19:39:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 02 Aug 2020 19:39:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=pHeBZp9 JySNxUWyKjC87M5BsPmmyme9M6OIA4/lwBJo=; b=nqHb+zvw0YXbvu7Rfj3Idb4 mc7W1PBG5JaF77wQE/hXB+l4k1p0Glqd8dGTg7KCgmFqRp+RvxrsG6Ip6IQklTw7 KNmX6MEJLufk3w2qgtbcjRBUmPe5T8FuB7t+oGR+LdPxjm1Y92l0U0Wtl4QLeJ3R x8YiDv21fgU7GqS7OMCfKMd9uQSGNxLWggeMLV9Yud8aI24SAGjVl+IUyNQF//iT xO4QO1K4rb3xXa4xX4cNju93RGz2n1KMtaOCTwziMm+34+NUhlEKqfV51hvxYvdZ VSoLA//rbPwOCHT/rS4Q4Sl7K5pxIgwzG6eFKDcCiQNAE//J/PjtsgQ0qp7Jrhg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pHeBZp 9JySNxUWyKjC87M5BsPmmyme9M6OIA4/lwBJo=; b=OsU5nBklK8xJcyCVo61oJ2 wctlNNmnW9L+MSlBwQRyEapoJp6nFpYNy7FnadydRXXP0BKRrUTRspva42IBvo5m yc7/XEeQorsi4ah3iH4F3uIsg3ZTbNbrX9wsex2FSR1VgYS6tW87CvIgz7+hOZNj 4g7L37C+oxHtLdh6fg1u8cRd7SBx42zAbG65PJ0RUceYYogaUlWO2NznJEa5L/gx rHyusTAjwAus8LB3924TV9kdNL81nD0FODN2IHCf+5RQGi8E8q0w7WKRdRAjc48Z tXO+HM5TlU5GnSb1H+HxkDTUrMOcehoEfTtj0my8ek+L5UENdKFKgUbhbqv8seiw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeefgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D0A618068F; Sun, 2 Aug 2020 19:39:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <2c74b7cb-ab53-45b9-a311-b7f19fac1f34@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 03 Aug 2020 09:39:53 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=bd2eec9a24784c9f95dc94cf40d0b013 Archived-At: Subject: Re: [calsify] jscalendar - offsetTrigger - offset X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 23:40:00 -0000 --bd2eec9a24784c9f95dc94cf40d0b013 Content-Type: text/plain On Mon, 3 Aug 2020, at 04:16, Michael Douglass wrote: > If the calendar object does not define a time zone, the user's default > time zone SHOULD be used when determining the offset, if known. > Otherwise, the time zone to use is implementation specific. > > Not sure what that means - is it supposed to be "when determining the > trigger time"? Yes**. > In any case isn't the first part sufficient? Presumably the client has > to deal with where the start/end lie already so it's just a matter of > applying the offset. I think I'm saying the language about timezones > belongs with start and end. Looking at this closely, I think I agree. I'll just cut those lines. Neil. --bd2eec9a24784c9f95dc94cf40d0b013 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 3 = Aug 2020, at 04:16, Michael Douglass wrote:
If the calendar object does not define = a time zone, the user's default 
time zone SHOULD be = used when determining the offset, if known. 
Otherwis= e, the time zone to use is implementation specific.

Not sure what that means - is it supposed to be "when determini= ng the 
trigger time"?
Yes.

In any case isn't the first part sufficient?= Presumably the client has 
to deal with where the st= art/end lie already so it's just a matter of 
applyin= g the offset. I think I'm saying the language about timezones 
<= /div>
belongs with start and end.

Looking at this closely, I think I agree. I'll just cut those li= nes.

Neil.
--bd2eec9a24784c9f95dc94cf40d0b013-- From nobody Sun Aug 2 16:46:32 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306763A0DCE for ; Sun, 2 Aug 2020 16:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wm245GhJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XM6sRX8E Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLBkYnFxFyJb for ; Sun, 2 Aug 2020 16:46:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A533A0DCC for ; Sun, 2 Aug 2020 16:46:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B5BB85C00BE for ; Sun, 2 Aug 2020 19:46:27 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 02 Aug 2020 19:46:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=grnnZWE bSaYtWtfOkpcaoNet9qQQbRQfCITFKe78+NA=; b=wm245GhJZejOYrv2uDEuRf0 0vlwll8nHaQ7EAGw4Sa0ePgrNvEzBizzhVSqejGrGyrEclPJefnlARia3bSoCR0Z CBskFA0CjYoTvfYUsxKJjvaFHqXX1zSpP6wXKNwN2vamujj7VEYJ9rBVRaDGz573 +BrJ4YHdy25VifrfG9MY9WygViQYxCkhoThmPNl92zZriGYxGXLUjj7DGfceo4At YYfqsUGZeBq7xp8fZol9f1/p/NOt87Mgkov2AIVoY42r02uqE5+5XH+BoCyDN4Ta fIND8Ed+2YpvMke5lesTOeN/xsL2VvySCFzeewS42DvsTKd3vYSmrP9/tGn2KYw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=grnnZW EbSaYtWtfOkpcaoNet9qQQbRQfCITFKe78+NA=; b=XM6sRX8EOspnb+Kt0nUUjE aV1xdmw2oVTvFpzz+Eou3fTlvLeQ+aKztfwISdjK4DuI/TSAuyU0qAyHSQaOtnM7 XDwyueIhRhTe/owI/yxDURSaOvDPAVE3Q6EgHKVAJFZcoTm6r98tNi+Gja4KCXYs B+OqVVQLOIxO6L21s6HSSpFq6x+W/7vS8w4mujSaBfeSSh50JRO/M2+Ve5gXuOEZ 0lyaA7/XvhSJkLEEozOzwhet0/SvTR8d1ShMdIKSyeOMiyjT3L5B5YENMj1jx0Tc wLVLsjpMKHKq1SaIM0CrLr27ZiNv9wy29+G6UGjcB0c9EU0xOanwLVhR/Bx8W2jg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeefgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeetkeevteejgeeike duhedviefffeeivdfghfejgeduieelueeiudehffehhfdugeenucffohhmrghinhepvgig rghmphhlvgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 34E0E18068F; Sun, 2 Aug 2020 19:46:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <70d70bca-44b9-4b20-a16a-b61832698e4d@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 03 Aug 2020 09:46:26 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3b6c30897a6545eb9fa8a28c0392d70e Archived-At: Subject: Re: [calsify] jscalendar: Vendor specific names and overrides X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 23:46:30 -0000 --3b6c30897a6545eb9fa8a28c0392d70e Content-Type: text/plain On Sun, 2 Aug 2020, at 14:19, Michael Douglass wrote: > Doesn't the construct > "example.com/customprop" > make it difficult to process overrides? It's possible (as per RFC6901 you can use ~1 to represent a literal forward slash), but that does mean you have to escape a top-level property and can't just use it verbatim, which seems awkward. Good point. > A different delimiter perhaps? Yes, I think colon will work better; I'll change it. Neil. --3b6c30897a6545eb9fa8a28c0392d70e Content-Type: text/html
On Sun, 2 Aug 2020, at 14:19, Michael Douglass wrote:
Doesn't the construct
make it difficult to process overrides?

It's possible (as per RFC6901 you can use ~1 to represent a literal forward slash), but that does mean you have to escape a top-level property and can't just use it verbatim, which seems awkward. Good point.

A different delimiter perhaps?

Yes, I think colon will work better; I'll change it.

Neil.
--3b6c30897a6545eb9fa8a28c0392d70e-- From nobody Sun Aug 2 18:35:08 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3718F3A0EB5 for ; Sun, 2 Aug 2020 18:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=e+nzv8im; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q1tRbII/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTfnJeG6bm7F for ; Sun, 2 Aug 2020 18:35:04 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8423C3A0EB4 for ; Sun, 2 Aug 2020 18:35:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C79DB5C00F9 for ; Sun, 2 Aug 2020 21:35:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 02 Aug 2020 21:35:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=IAiVP32 uaon7Dui9Jpl6cbOkRNrevG5irNePIwFCJKE=; b=e+nzv8im8Lxcy7cNdLJjAN5 vbW/PVkf6QPiRj5BGGU6GBnkafGX1yriqxfP7fnoJPU81J4iGx7YMCxO6XY4U5QL EaEqa0KBN0sR2vIJ+XZKdfyBMyxuNEd8npNlngaZzQ5G49hq0wKvV3GyoD9u8rsQ MOUqQhsujlxsj+HJdqGJzsOhIz7nOmr8gqtx7I5NRJ0FMp+zkA12S8tjCnlV49mm 8JLCAmpbKBWkdwb+pAWXnnd7qkYswlsaHfA4maHoA1Nv/YwRjr2qdzJ9gFnB43L+ NIsVMxy/FVPMHFtmbzYh8HFnG61sRQkTQFGhWygQG/D088PRhfCJdSowd2Wquzw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=IAiVP3 2uaon7Dui9Jpl6cbOkRNrevG5irNePIwFCJKE=; b=q1tRbII/vn7jaXV1H9++Rt UPnpD/u2KA3a97nd+zrmUoijaUPah/qwu+0NFrMLa/Ozz6e+wMH0UbskzPTtYhDW IE+PBtMRosQT2B2dCR8uhWsmFKF9EjAzH5rI0zRFO4kfitRHeoq6bO9UzRa5J8f9 eopJi/ZY+RbODbo9TS1CIytTF8I9Fren7812XoNtU4arTMITlBg7B6w1P3xAadA2 x3QrvJwoyAZZgnPvYhEZTLIMKQK4XjI5bzLIxCmrfGukPhFrkV3ikOz5pb7vONgm YIi4BYx+FIW15gSj/+NNccT2y2LpbkK22JKx4qpcBz9SwAyR3OJzeBLr7xVdUtGA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeefgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7129E18057E; Sun, 2 Aug 2020 21:35:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 03 Aug 2020 11:35:02 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=80b09d0a88be4374b279264097ca5157 Archived-At: Subject: Re: [calsify] =?utf-8?q?RFC_5545/JSCalendar_questions_from_ECMAScrip?= =?utf-8?q?t_TC39_=22Temporal=22_working_group?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 01:35:06 -0000 --80b09d0a88be4374b279264097ca5157 Content-Type: text/plain On Sun, 2 Aug 2020, at 13:04, Justin Grant wrote: > > Q1. [...] I'm not sure why you think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where it happens? > > Here's an example: what should be the result of adding P1DT12H to 2020-03-07T02:30-08:00[America/Los_Angeles]. My understanding of RFC5545's algorithm is that we'd use the following steps: > A) Add 1 calendar day. > B) Add 12 exact hours (not clock hours) > But the after step A, the local time is not valid because 2020-03-08T02:30 is in the middle of the hour skipped by a DST transition. My interpretation of RFC 5545 is that we'd interpret the invalid intermediate time by using the offset before the transition, so we'd end up with an intermediate value of 2020-03-08T03:30-07:00[America/Los_Angeles] and a final result of 2020-03-08T15:30-07:00[America/Los_Angeles]. Is this correct? Yes, that's my understanding too. > Are both of these compliant with your understanding of RFC 5545? Is only one correct? Or is neither correct? > > One problem is that the Addition Path and the Subtraction Path can return different results when an endpoint is in the "repeated hour" after DST ends in the fall. For example, assume that X is 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the day DST ends). OK, so I think I see the cause of the confusion. They are both correct(!) BUT this is because there is a subtle difference between the Temporal *LocalDateTime* and RFC5545 *Date with local time and time zone reference*. The latter does not have a UTC reference point; it's just a wall clock time. You can add either P1D or P1DT1H to 2020-10-31T01:30 and get a wall clock time of 2020-11-01T01:30. Both are correct durations to calculate as the difference between X and Y, because Y could be two different absolute times (the -08:00 is not encoded in the RFC5545 model). Due to conversion rules, when converting to UTC you always interpret 2020-11-01T01:30[America/Los_Angeles] as -07:00, not -08:00, should you need an absolute time. If you want to reference the other point in time specifically you would need to use UTC (or I guess any time zone where it is unambiguous). Note, in general the lack of offset encoded with the time zone is a feature not a bug; otherwise you end up with nonsensical data should the time zone definitions change (what would you do with 2020-11-01T01:30-08:00[America/Los_Angeles] should California suddenly decide to join the One Glorious US Average Time Zone of -06:30?!). If the offset is fixed, you need to use UTC (or a fixed offset zone like Etc/GMT+8), not a real time zone. > Another problem is that the logic above can deliver unexpected results depending on the local time of the endpoints, even if neither of those endpoints are close to a DST transition. For example, using the "Addition Path" logic above, here's the durations that the following pairs of LocalDateTime values will return: > * 2020-03-07T01:30-08:00[America/Los_Angeles] to 2020-03-08T13:30-07:00[America/Los_Angeles] => P1D12H I think this one is incorrect. Following your Addition Path algorithm: A) Let D = Y - X => 1 day 12 hours B) Truncate the time portion of D => 1 day C) Let I = X+D => 2020-03-08T01:30[America/Los_Angeles] => 2020-03-08T09:30:00Z D) Y = 2020-03-08T20:30:00Z; I - Y => 11H E) Merge N and T: P1DT11H > * 2020-03-07T02:30-08:00[America/Los_Angeles] to 2020-03-08T14:30-07:00[America/Los_Angeles] => P1D11H (1 hour less because the intermediate time 2020-03-08T02:30 is resolved to 2020-03-08T03:30-07:00[America/Los_Angeles] before the exact time difference is calculated) > * 2020-03-07T03:30-08:00[America/Los_Angeles] to 2020-03-08T15:30-07:00[America/Los_Angeles] => P1D12H > > Users probably won't be surprised to see divergent results in cases where the endpoints are within an hour of a DST transition. But what's unexpected is the variation in results caused by the intermediate result landing on an invalid time, even though neither of the endpoints are very close to the transition. > > Does this clarify the problems we're trying to resolve with Q5? I think I see. So the issue you have is if the end day is a daylight savings transition *day* and the start time is prior to the daylight savings transition *time*, then you have the intermediate adjustment which may be surprising to users. Firstly, this is actually going to be very rare that you hit it (so the likelihood of someone coming across it and actually *being *surprised is minimal, and the issue is the surprise, not necessarily the semantics); secondly, I think you would have to change the interpretation of durations (Q1) in order to do anything different, which seems a breaking change for minimal gain in my view. Neil. --80b09d0a88be4374b279264097ca5157 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, 2 = Aug 2020, at 13:04, Justin Grant wrote:
> Q1. [...] I'm not sure why you think the disambiguati= on in the middle is going to be problematic for users; surely they generally won't notice where it= happens? 

Here's an example: what shou= ld be the result of adding P1DT12H to 2020-03-07T02:30-08:00[Americ= a/Los_Angeles]. My understanding of RFC5545's algorithm is that we'd use= the following steps:
  A) Add 1 calendar day.
  B) Add 12 exact hours (not clock hours)
But= the after step A, the local time is not valid because 2020-03-08T0= 2:30 is in the middle of the hour skipped by a DST transition. My interp= retation of RFC 5545 is that we'd interpret the invalid intermediate tim= e by using the offset before the transition, so we'd end up with an inte= rmediate value of 2020-03-08T03:30-07:00[America/Los_Angeles] and a fina= l result of 2020-03-08T15:30-07:00[America/Los_Angeles].  Is this c= orrect?

Yes, that's my underst= anding too.

Are both of these compliant with your understanding of R= FC 5545?  Is only one correct?  Or is neither correct?

One problem is that the Addition Path and the Subt= raction Path can return different results when an endpoint is in the "re= peated hour" after DST ends in the fall. For example, assume that X is 2= 020-10-31T01:30-07:00[America/Los_Angeles] and Y is 2020-11-01T01:3= 0-08:00[America/Los_Angeles] (the "second" 1:30AM on the day DST ends).<= br>

OK, so I think I see the= cause of the confusion. They are both correct(!) BUT this is because th= ere is a subtle difference between the Temporal LocalDateTime and= RFC5545 Date with local time and time zone reference. The latter= does not have a UTC reference point; it's just a wall clock time.

You can add either P1D or P1DT1H to 2020-10-31T0= 1:30 and get a wall clock time of 2020-11-01T01:30. Both are correct dur= ations to calculate as the difference between X and Y, because Y could b= e two different absolute times (the -08:00 is not encoded in the RFC5545= model).

Due to conversion rules, when conv= erting to UTC you always interpret 2020-11-01T01:30[America/Los_Angeles]= as -07:00, not -08:00, should you need an absolute time. If you want to= reference the other point in time specifically you would need to use UT= C (or I guess any time zone where it is unambiguous).

=
Note, in general the lack of offset encoded with the time zon= e is a feature not a bug; otherwise you end up with nonsensical data sho= uld the time zone definitions change (what would you do with 2020-11-01T= 01:30-08:00[America/Los_Angeles] should California suddenly decide to jo= in the One Glorious US Average Time Zone of -06:30?!). If the offset is = fixed, you need to use UTC (or a fixed offset zone like Etc/GMT+8), not = a real time zone.

Another problem is that the logic above can deliv= er unexpected results depending on the local time of the endpoints, even= if neither of those endpoints are close to a DST transition.  For = example, using the "Addition Path" logic above, here's the durations tha= t the following pairs of LocalDateTime values will return: 
  • 2020-03-07T01:30-08:00[America/Los_Angeles] to 2020-= 03-08T13:30-07:00[America/Los_Angeles] =3D> P1D12H

I think this one is incorr= ect. Following your Addition Path algorithm:

  A) Let D =3D Y - X =3D> 1 day 12 hours
  = B) Truncate the time portion of D =3D> 1 day
  C) = Let I =3D X+D =3D> 2020-03-08T01:30[America/Los_Angeles] =3D> 2020= -03-08T09:30:00Z
  D) Y =3D 2020-03-08T20:30:00Z; I -= Y =3D> 11H
  E) Merge N and T: P1DT11H
<= div>
    <= li>2020-03-07T02:30-08:00[America/Los_Angeles] to 2020-03-08T14:30-= 07:00[America/Los_Angeles] =3D> P1D11H (1 hour less because the inter= mediate time 2020-03-08T02:30 is resolved to 2020-03-08T03:30-= 07:00[America/Los_Angeles] before the exact time difference is calculate= d)
  • 2020-03-07T03:30-08:00[America/Los_Angeles] to 2020-= 03-08T15:30-07:00[America/Los_Angeles] =3D> P1D12H

Users probably won't be surprised to see dive= rgent results in cases where the endpoints are within an hour of a DST t= ransition. But what's unexpected is the variation in results caused by t= he intermediate result landing on an invalid time, even though neit= her of the endpoints are very close to the transition.
Does this clarify the problems we're trying to res= olve with Q5?

I think I = see. So the issue you have is if the end day is a daylight savings trans= ition day and the start time is prior to the daylight savings tra= nsition time, then you have the intermediate adjustment which may= be surprising to users. Firstly, this is actually going to be very rare= that you hit it (so the likelihood of someone coming across it and actu= ally being surprised is minimal, and the issue is the surprise, n= ot necessarily the semantics); secondly, I think you would have to chang= e the interpretation of durations (Q1) in order to do anything different= , which seems a breaking change for minimal gain in my view.

Neil.
--80b09d0a88be4374b279264097ca5157-- From nobody Sun Aug 2 21:47:04 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA33A0A3F for ; Sun, 2 Aug 2020 21:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYUxZLmVTTUw for ; Sun, 2 Aug 2020 21:46:59 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1EE3A0A4E for ; Sun, 2 Aug 2020 21:46:59 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id i6so645704edy.5 for ; Sun, 02 Aug 2020 21:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3O/tO2rX+MywN2Sv8P8UZUVt24OpyuxV2hPGI2y5RLA=; b=apmsHe8e5SI73pvpt4WgRrU5R3ZOpwHCiSTfkpAY1/T/Im8INEGOLUC20bnBjLyo/o io7X0FZif5S26q6LfLvXLQN/NsCgHQXf0XSu0bo6uuv+PQm3KuQM3ddBYpX3PLXuyFAI YqifIBhCyq6hgo7dESAiCR5grxkmkMjnXrdKQOp8CEreB+vvTUlY4K5pnFJ13LFkex2C kmFkjwoPEe4CFB+0zut+uElt+GNDA8aHzmHqHyJ9MJDpg0h9SkdcTsD2eAo6SBgY+Osa rGhYTCKBK56PDkiKkBalF3QckLwzhHwOOn+7foybSG42+GZ1/0saasKXbOyYUdWbiyt0 d/tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3O/tO2rX+MywN2Sv8P8UZUVt24OpyuxV2hPGI2y5RLA=; b=ocXPthsMmZTiztDT0NcJTSAOzvizwEvKj81Jnj19Q/w/ulLtON8pMbmnXxe7/KMDTX CxpJdLY853nI+5QjuV6iYWOBsMAhwex8jdf4lTOkhgFFIxupULBgmMfl1mrgH/RIEhhE 9ZEUCbZarsWOc/LcbLAETBQci3Hm9B+x12udoxoNiqbVZs/dQ3kJxs//XkqGE03NOP0r Phhvwk+5O/FQOQ3L0mk8Dmxl/kZQ6I7lx/W+5zpbOTSIBqvQZc0AUu+Y+srozPJQOe82 ioRh3zcak4ySl3WVJmxUfYDJBMcdjzHWwvbpNKjbSTrcVYJcTcNfoaPfgFosUmBCw/+R 2SpA== X-Gm-Message-State: AOAM532yyOxYy68XJus3noeKm1zRmJoF8SGHZXW70LDoUF+Aw3w9GUrz C6c9/+w3Y3rz1RHTJ/GmS+lVwU/NLm6ETdFAuENFJJuN X-Google-Smtp-Source: ABdhPJzo2g2hTNv3qBALuA0P8mE4gFidGjjc5tjb3ZkayY8Mt1W+kCz+v8qyFJlRXblnn777Y4dctBTHx2kp8ZNhwoA= X-Received: by 2002:a50:d784:: with SMTP id w4mr14394490edi.34.1596430017729; Sun, 02 Aug 2020 21:46:57 -0700 (PDT) MIME-Version: 1.0 References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> In-Reply-To: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> From: Justin Grant Date: Sun, 2 Aug 2020 21:46:46 -0700 Message-ID: To: Neil Jenkins Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d981105abf1d414" Archived-At: Subject: Re: [calsify] RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 04:47:02 -0000 --0000000000001d981105abf1d414 Content-Type: text/plain; charset="UTF-8" Hi Neil - Thanks for the quick reply. It's very useful to understand how your team is thinking through these problems. Overall I agree with everything in your reply. Here's a few notes: Note, in general the lack of offset encoded with the time zone is a feature > not a bug; otherwise you end up with nonsensical data should the time zone > definitions change (what would you do with > 2020-11-01T01:30-08:00[America/Los_Angeles] should California suddenly > decide to join the One Glorious US Average Time Zone of -06:30?!). If the > offset is fixed, you need to use UTC (or a fixed offset zone like > Etc/GMT+8), not a real time zone. Yep, we're aware of this problem but planning to handle it a little differently. Many JS developers have limited understanding of time zones so won't know whether to store UTC+timezone or date/time+timezone, and even more JS won't anticipate how time zone definition changes can revise the meaning of previously-stored values. The case we want to avoid is where developers realize too late that their stored-long-ago data is ambiguous or wrong. For these reasons, by default we'll persist both the offset and the IANA time zone, e.g. 2020-11-01T01:30-08:00[America/Los_Angeles]. This ensures that no data is lost in serialization. When developers discover the problem (probably soon after the new time zone definition takes effect!) they can fix it by making a small change to parsing code, instead of a painful fixup of already-stored data. More sophisticated developers who know exactly what they want to store can omit either the offset or the time zone when persisting, but at least the default serialization format is not lossy. In the deserialization API, developers will have an option to control whether the offset or the time zone should "win" when converting the nominal date/time value to UTC. The default is to throw an exception if there's a conflict, but users can override so that the time zone or the offset can win. I think this one is incorrect. Yep, you're right. Good catch. I think I see. So the issue you have is if the end day is a daylight > savings transition *day* and the start time is prior to the daylight > savings transition *time*, then you have the intermediate adjustment > which may be surprising to users. Firstly, this is actually going to be > very rare that you hit it (so the likelihood of someone coming across it > and actually *being *surprised is minimal, and the issue is the surprise, > not necessarily the semantics); secondly, I think you would have to change > the interpretation of durations (Q1) in order to do anything different, > which seems a breaking change for minimal gain in my view. > Yep, agreed. This is a rare use case so it's definitely not worth a breaking change. Our goal is to find a deterministic, least-surprising solution for this weird case. Ideally someone else would have already standardized how to handle this case and we could just adopt the standard, but so far I haven't found it. Does JSCalendar include any guidance about how to calculate durations from two date/time+timezone (DATE-TIME - FORM #3) values? If not, would you be interested in collaborating with us to define an algorithm that could be used by Temporal and included in the JSCalendar spec? This may help with interop. Finally, could you explain what you mean by "*I think you would have to change the interpretation of durations (Q1) in order to do anything different"* ? Cheers, Justin On Sun, Aug 2, 2020 at 6:35 PM Neil Jenkins wrote: > On Sun, 2 Aug 2020, at 13:04, Justin Grant wrote: > > > Q1. [...] I'm not sure why you think the disambiguation in the middle is > going to be problematic for users; surely they generally won't notice where > it happens? > > Here's an example: what should be the result of adding P1DT12H > to 2020-03-07T02:30-08:00[America/Los_Angeles]. My understanding of > RFC5545's algorithm is that we'd use the following steps: > A) Add 1 calendar day. > B) Add 12 exact hours (not clock hours) > But the after step A, the local time is not valid because 2020-03-08T02:30 > is in the middle of the hour skipped by a DST transition. My interpretation > of RFC 5545 is that we'd interpret the invalid intermediate time by using > the offset before the transition, so we'd end up with an intermediate value > of 2020-03-08T03:30-07:00[America/Los_Angeles] and a final result of > 2020-03-08T15:30-07:00[America/Los_Angeles]. Is this correct? > > > Yes, that's my understanding too. > > Are both of these compliant with your understanding of RFC 5545? Is only > one correct? Or is neither correct? > > One problem is that the Addition Path and the Subtraction Path can return > different results when an endpoint is in the "repeated hour" after DST ends > in the fall. For example, assume that X is > 2020-10-31T01:30-07:00[America/Los_Angeles] and Y > is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the > day DST ends). > > > OK, so I think I see the cause of the confusion. They are both correct(!) > BUT this is because there is a subtle difference between the Temporal > *LocalDateTime* and RFC5545 *Date with local time and time zone reference*. > The latter does not have a UTC reference point; it's just a wall clock time. > > You can add either P1D or P1DT1H to 2020-10-31T01:30 and get a wall clock > time of 2020-11-01T01:30. Both are correct durations to calculate as the > difference between X and Y, because Y could be two different absolute times > (the -08:00 is not encoded in the RFC5545 model). > > Due to conversion rules, when converting to UTC you always interpret > 2020-11-01T01:30[America/Los_Angeles] as -07:00, not -08:00, should you > need an absolute time. If you want to reference the other point in time > specifically you would need to use UTC (or I guess any time zone where it > is unambiguous). > > Note, in general the lack of offset encoded with the time zone is a > feature not a bug; otherwise you end up with nonsensical data should the > time zone definitions change (what would you do with > 2020-11-01T01:30-08:00[America/Los_Angeles] should California suddenly > decide to join the One Glorious US Average Time Zone of -06:30?!). If the > offset is fixed, you need to use UTC (or a fixed offset zone like > Etc/GMT+8), not a real time zone. > > Another problem is that the logic above can deliver unexpected results > depending on the local time of the endpoints, even if neither of those > endpoints are close to a DST transition. For example, using the "Addition > Path" logic above, here's the durations that the following pairs of > LocalDateTime values will return: > > - 2020-03-07T01:30-08:00[America/Los_Angeles] > to 2020-03-08T13:30-07:00[America/Los_Angeles] => P1D12H > > > I think this one is incorrect. Following your Addition Path algorithm: > > A) Let D = Y - X => 1 day 12 hours > B) Truncate the time portion of D => 1 day > C) Let I = X+D => 2020-03-08T01:30[America/Los_Angeles] => > 2020-03-08T09:30:00Z > D) Y = 2020-03-08T20:30:00Z; I - Y => 11H > E) Merge N and T: P1DT11H > > > - 2020-03-07T02:30-08:00[America/Los_Angeles] > to 2020-03-08T14:30-07:00[America/Los_Angeles] => P1D11H (1 hour less > because the intermediate time 2020-03-08T02:30 is resolved > to 2020-03-08T03:30-07:00[America/Los_Angeles] before the exact time > difference is calculated) > - 2020-03-07T03:30-08:00[America/Los_Angeles] > to 2020-03-08T15:30-07:00[America/Los_Angeles] => P1D12H > > > Users probably won't be surprised to see divergent results in cases where > the endpoints are within an hour of a DST transition. But what's unexpected > is the variation in results caused by the intermediate result landing on an > invalid time, even though neither of the endpoints are very close to the > transition. > > Does this clarify the problems we're trying to resolve with Q5? > > > I think I see. So the issue you have is if the end day is a daylight > savings transition *day* and the start time is prior to the daylight > savings transition *time*, then you have the intermediate adjustment > which may be surprising to users. Firstly, this is actually going to be > very rare that you hit it (so the likelihood of someone coming across it > and actually *being *surprised is minimal, and the issue is the surprise, > not necessarily the semantics); secondly, I think you would have to change > the interpretation of durations (Q1) in order to do anything different, > which seems a breaking change for minimal gain in my view. > > Neil. > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000001d981105abf1d414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil - Thanks for the quick reply. It&= #39;s very useful to understand how your team is thinking through these pro= blems. Overall I agree with everything in your reply. Here's a few note= s:=C2=A0

No= te, in general the lack of offset encoded with the time zone is a feature n= ot a bug; otherwise you end up with nonsensical data should the time zone d= efinitions change (what would you do with 2020-11-01T01:30-08:00[America/Lo= s_Angeles] should California suddenly decide to join the One Glorious US Av= erage Time Zone of -06:30?!). If the offset is fixed, you need to use UTC (= or a fixed offset zone like Etc/GMT+8), not a real time zone.=C2=A0

Yep, we're aware of this problem but planning = to handle it a little differently. Many JS developers have limited understa= nding of time zones so won't know whether to=C2=A0store UTC+timezone or= date/time+timezone, and even more JS won't anticipate how time zone de= finition changes can revise the meaning of previously-stored values. The ca= se we want to avoid is where developers realize too late that their stored-= long-ago data is ambiguous or wrong. For these reasons, by default we'l= l persist both the offset and the IANA time zone, e.g. 2020-11-01T01:30-08:= 00[America/Los_Angeles]. This ensures that no data is lost in serialization= . When developers discover the problem (probably soon after the new time zo= ne definition takes effect!) they can fix it by making a small change to pa= rsing code, instead of a painful fixup of already-stored data. More sophist= icated developers who know exactly what they want to store can omit either = the offset or the time zone when persisting, but at least the default seria= lization format is not lossy.

In the deserializati= on API, developers will have an option to control whether the offset or the= time zone should "win" when converting the nominal date/time val= ue to UTC.=C2=A0 The default is to throw an exception if there's a conf= lict, but users can override so that the time zone or the offset can win.

I thin= k this one is incorrect.=C2=A0

Yep, you'= ;re right. Good catch.

I think I see. So the issue you have is if the end d= ay is a daylight savings transition=C2=A0day=C2=A0and the start time= is prior to the daylight savings transition=C2=A0time, then you hav= e the intermediate adjustment which may be surprising to users. Firstly, th= is is actually going to be very rare that you hit it (so the likelihood of = someone coming across it and actually=C2=A0being=C2=A0surprised is m= inimal, and the issue is the surprise, not necessarily the semantics); seco= ndly, I think you would have to change the interpretation of durations (Q1)= in order to do anything different, which seems a breaking change for minim= al gain in my view.

Yep, agreed. = This is a rare use case so it's definitely not worth a breaking change.= Our goal is to find a deterministic, least-surprising solution for this we= ird case.=C2=A0 Ideally someone else would have already standardized how to= handle this case and we could just adopt the standard, but so far I haven&= #39;t found it.

Does JSCalendar include any guidance about ho= w to calculate durations from two date/time+timezone (DATE-TIME -=C2=A0FORM #3) values?=C2= =A0 If not, would you be interested in collaborating with us to define an a= lgorithm that could be used by Temporal and included in the JSCalendar spec= ? This may help with interop.

Finally, could you e= xplain what you mean by "I think you would have to change the inter= pretation of durations (Q1) in order to do anything different"=C2= =A0?

Cheers,=C2=A0
Justin

=

On Sun, Aug 2, 2020 at 6:35 PM Neil Jenkins <neilj@fastmailteam.com> wrote:
=
On Sun, 2 Aug 2020, at 13:04, Justin Grant wrote:
<= blockquote type=3D"cite">
> Q1. [...]=C2=A0I'm not sure why you = think the disambiguation in the middle is going to be problematic for users; surely they generally won't notice where i= t happens?=C2=A0

Here's an example: what sho= uld be the result of adding P1DT12H to=C2=A02020-03-07T02:30-08:00[America/= Los_Angeles]. My understanding of RFC5545's algorithm is that we'd = use the following steps:
=C2=A0 A) Add 1 calendar day.
=C2=A0 B) Add 12 exact hours (not clock hours)
But th= e after step A, the local time is not valid because=C2=A02020-03-08T02:30 i= s in the middle of the hour skipped by a DST transition. My interpretation = of RFC 5545 is that we'd interpret the invalid intermediate time by usi= ng the offset before the transition, so we'd end up with an intermediat= e value of 2020-03-08T03:30-07:00[America/Los_Angeles] and a final result o= f 2020-03-08T15:30-07:00[America/Los_Angeles].=C2=A0 Is this correct?


=





Another problem is that the logic above can deliver= unexpected results depending on the local time of the endpoints, even if n= either of those endpoints are close to a DST transition.=C2=A0 For example,= using the "Addition Path" logic above, here's the durations = that the following pairs of LocalDateTime values will return:=C2=A0
  • 2020-03-07T01:30-08:00[America/Los_Angeles] to=C2=A02020-03-= 08T13:30-07:00[America/Los_Angeles] =3D> P1D12H


=C2=A0 C) Let I =3D X+D =3D&= gt; 2020-03-08T01:30[America/Los_Angeles] =3D> 2020-03-08T09:30:00Z
<= /div>
=C2=A0 D) Y =3D 2020-03-08T20:30:00Z; I - Y =3D> 11H
=
=C2=A0 E) Merge N and T: P1DT11H

  • 2020-03-07T02:30-08:00[Amer= ica/Los_Angeles] to=C2=A02020-03-08T14:30-07:00[America/Los_Angeles] =3D>= ; P1D11H (1 hour less because the intermediate time=C2=A02020-03-08T02:30 i= s resolved to=C2=A02020-03-08T03:30-07:00[America/Los_Angeles] before the e= xact time difference is calculated)
  • 2020-03-07T03:30-08:00[Amer= ica/Los_Angeles] to=C2=A02020-03-08T15:30-07:00[America/Los_Angeles] =3D>= ; P1D12H

Users probably won= 9;t be surprised to see divergent results in cases where the endpoints are = within an hour of a DST transition. But what's unexpected is the variat= ion in results caused by the intermediate result landing on an invalid time= ,=C2=A0even though neither of the endpoints are very close to the transitio= n.

Does this clarify the problems=C2=A0we'= re=C2=A0trying to resolve with Q5?
--0000000000001d981105abf1d414-- From nobody Mon Aug 3 16:53:26 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514773A0DBE for ; Mon, 3 Aug 2020 16:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Hfo8V8ue; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nc6qleJF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS6NVf2KFxxG for ; Mon, 3 Aug 2020 16:53:23 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64F03A0D89 for ; Mon, 3 Aug 2020 16:53:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D16565C01A7; Mon, 3 Aug 2020 19:53:22 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 03 Aug 2020 19:53:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=yE2yIvo5obru41tNA3mXU9zlV1eJ7I6soTaXSlZ nyVA=; b=Hfo8V8ued303pvhDoYNaxR5FyKHBO0xBcm3RTUHpQjBUQIl/cQi6YMm 9rdd6sR0WvvaIfhg7uZQyBpb0GCYSuaZj0YP9vSAl96YJNXEDKBxbf78dXWNhJW5 /7nUqPlAx2VjjvcMSx6lvngEjK7eUSfvPUSJLIKYELc9sRaTZOws43qkdULxMqCK VMzATi12hjL7DOLuf7B2HFt/S4qGl2KRwp+V83ktN97mpuyriaxgWEHK5BKHh+NC Oe419w1q/I2QTLinT31eoY9l/6YMl/45kO2sjcJovnndPKwZ1z6aEpgSzG4QBGU7 Kzv/6pq/BSLy9UdnfTQyrnwsim5z6zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=yE2yIvo5obru41tNA3mXU9zlV1eJ7 I6soTaXSlZnyVA=; b=nc6qleJFV84dP8UTLU2N/p8iGTbxTPVUxxny9hq8L8fSh 4bys+f2Rz4tU6PhsjtNTj3i5oHxVUKcMPuFIcCeQlr+yeRnnKnU2LW056nPrFW2d 8Z9nhk7eIbB1moL0tm1JCJ3Yc9EqODbOlAZuixsdURzDfhdLGt9JeafjfQADq2cg zjYNvzaHMjkHZFxhbe43dM+HXdcQAAvZ4tDyz9PGk0OgzpOoPNmVGxGUGJe0SmKH n/ltDFjNL9WUjSAkwwX0vuahu8b0rS2MA65DZtBcHPB0X47zRlIS44ipmzzxy7ID 99RAAWFsAYmn6c9ACqOKOrEf4LcD6Q/ksBc0HAMKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeehgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ggtffrrghtthgvrhhnpeegteeiuddtudduveekffelgfegkefhkefgfedvkeevtdejgeff gfdtleefjefggfenucffohhmrghinhepvgigrghmphhlvgdrtghomhenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 76FB71804C6; Mon, 3 Aug 2020 19:53:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> Date: Tue, 04 Aug 2020 09:52:53 +1000 From: "Bron Gondwana" To: calsify@ietf.org, "Douglass Mike" Content-Type: multipart/alternative; boundary=0cd0e6ff84604422bad1c46609471714 Archived-At: Subject: [calsify] Review: draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 23:53:25 -0000 --0cd0e6ff84604422bad1c46609471714 Content-Type: text/plain Hi Mike, Thanks for uploading the latest ical relations. Here's a quick review of a couple of tiny changes needed! And I need you to confirm that there's no IPR that you're aware of :) Thanks, Bron. *REVIEW: * *Abstract: * nits complains: ** The abstract seems to contain references ([RFC5545]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Please change it not to be a reference in the Abstract (it's OK to have a reference in the Introduction) *1.4 Link* See [I-D.daboo-caldav-attachments] Please update this reference to be RFC8607. *7.1. Concept* There's a bug in the example: SCONCEPT:http://example.com/event-types/sports CONCEPT:http://example.com/event-types/arts/music CONCEPT:http://example.com/task-types/delivery Please remove the leading 'S'! ... I think that's everything I can see :) Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --0cd0e6ff84604422bad1c46609471714 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Mike,

Thanks for uploading the latest ic= al relations.  Here's a quick review of a couple of tiny changes ne= eded!

And I need you to confirm that there's no IPR that = you're aware of :)

=
Thanks,

Bron.
=

REVIEW:

Abstract:

nits= complains:

  =
** The abstract seems to contain references ([RFC5545]), which it
     shouldn't.  Please replace those with straight textual mentions of =
the
     documents in question.
<= br>
Please change it not to be a = reference in the Abstract (it's OK to have a reference in the Introducti= on)

1.4 Link

&nb= sp;   See [I-D.daboo-caldav-attachments]
=

Please update this reference to be RFC8607.
= 

7.1. Concept

There's a bug in the example:

     SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http:=
//example.com/event-types/arts/music
     CONCEPT:http://e=
xample.com/task-types/delivery

Please remove the lead= ing 'S'!

...
<= br>
I think that's everything I c= an see :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
 = ; brong@fastmailteam.com


--0cd0e6ff84604422bad1c46609471714-- From nobody Mon Aug 3 20:35:30 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63713A0A8C for ; Mon, 3 Aug 2020 20:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=vsb5L0bp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AJAc/iWZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRvAboTiBptE for ; Mon, 3 Aug 2020 20:35:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6CF3A0A6E for ; Mon, 3 Aug 2020 20:34:51 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E386D5C0086; Mon, 3 Aug 2020 23:34:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 03 Aug 2020 23:34:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=Wb0J d8EwvbLNyu5qt6CmZN22W1IC45V6GBBUMR6hgRY=; b=vsb5L0bpoZ8XhDuw4FIJ YYwVfJGe0fzYtUP2HFZpf2DlblmdugVC1p/Z9jut5yDB9+G/pzrRHgZFms7JIrD1 ZdcYrQ+er+a+3Kt7RsodayXNS5NJpaUTrJXCNPHMiSyy5+JUYZtTVs3o2UAzjO2O QK5H/jzF6UmdkF0KgdsIvkNZmhoMMMIF0AF5icUyGLVTHQAp0zF0yjHM4rg/CMAz qC+i/6v/TwH8xokSkt7ZUuSclc8QN9l+hYC3mecY7KVV+OVbSnDeBd8eqHtGx6dq VP+ZP5/QHYgskeJ7xW5Lm42SCelPihAPVLvFgX70nP8Uy9y6qPK/h2IcCiDf9vY3 mg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Wb0Jd8 EwvbLNyu5qt6CmZN22W1IC45V6GBBUMR6hgRY=; b=AJAc/iWZPY7vI762/fWWHu j7BxDd8R6fYPGQpMi1Vpuz2B6rtIVPPPRCm1kNHYm+YoIHy0eTBnXInu0r7hMMnh 4wtWlbv2AuUIr1DkKyjrJA5i4mMAYvhT6vs2W3L4gaL6OUT25QcAziMiVC58G7rC 1yEmVYNQFnWwXHIwATKhOsep2Imx1OXq+pRiYnr65uTTpjH4fqTbHNwx4b7HWyTk cAEmKRUy36fpxApHcEwhvdju94dy1VRZv+r1gNcYKm34JJNbhDmaBnZ1bw1pljiS cTPpb/tRoiDRz7Pe31n+MBjYKI2wubasyij2tQQb1yyHwqGdJE5GIod/szAUQ9vA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeehgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9BE3F1804C6; Mon, 3 Aug 2020 23:34:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-136-gc39b634-fm-20200803.001-gc39b6340 Mime-Version: 1.0 Message-Id: <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> In-Reply-To: References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> Date: Tue, 04 Aug 2020 13:34:49 +1000 From: "Neil Jenkins" To: "Justin Grant" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=c67f31cfdd564eb19720a3a21c0126ce Archived-At: Subject: Re: [calsify] =?utf-8?q?RFC_5545/JSCalendar_questions_from_ECMAScrip?= =?utf-8?q?t_TC39_=22Temporal=22_working_group?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 03:35:30 -0000 --c67f31cfdd564eb19720a3a21c0126ce Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 3 Aug 2020, at 14:46, Justin Grant wrote: > Yep, agreed. This is a rare use case so it's definitely not worth a br= eaking change. Our goal is to find a deterministic, least-surprising sol= ution for this weird case. Ideally someone else would have already stan= dardized how to handle this case and we could just adopt the standard, b= ut so far I haven't found it. >=20 > Does JSCalendar include any guidance about how to calculate durations = from two date/time+timezone (DATE-TIME - FORM #3) values? If not, would= you be interested in collaborating with us to define an algorithm that = could be used by Temporal and included in the JSCalendar spec? This may = help with interop. We don't have anything currently defined, but I am interested in adding = it; I agree it could be useful for interop. > Finally, could you explain what you mean by "*I think you would have t= o change the interpretation of durations (Q1) in order to do anything di= fferent"* ? What I mean is that the addition operation of a duration to a date is we= ll defined, and we don't plan to change it. Therefore, the =E2=80=9Ccorr= ectness=E2=80=9D of an algorithm for calculating a duration between date= s X and Y is constrained by the simple fact that the duration "D" that r= esults must be such that X + D =3D Y. The Temporal case is further constrained because you are representing bo= th sets of dates in overlapping time periods. Therefore to go back to th= e example you gave in the previous email: > One problem is that the Addition Path and the Subtraction Path can ret= urn different results when an endpoint is in the "repeated hour" after D= ST ends in the fall. For example, assume that X is 2020-10-31T01:30-07:0= 0[America/Los_Angeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angel= es] (the "second" 1:30AM on the day DST ends). If we start from X, then= we'd add one nominal day to get 2020-11-01T01:30-07:00[America/Los_Ange= les] (the "first" 1:30AM), and then add one exact hour to get to the end= . So the result is P1DT1H. But if we start from Y, then subtracting one= nominal day from 2020-11-01T01:30-08:00[America/Los_Angeles] yields 202= 0-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So= the result is P1D. As I said before, both of these durations are arguably valid in RFC5545.= However in Temporal, the Subtraction one is not valid: * X =3D 2020-10-31T01:30-07:00[America/Los_Angeles] * Y =3D 2020-11-01T01:30-08:00[America/Los_Angeles] * D =3D P1D (by the subtraction method) * X + D =3D 2020-11-01T01:30-07:00[America/Los_Angeles] =E2=89=A0 Y The "Addition" algorithm however does produce the correct result, and I = think is a reasonable basis for an algorithm to adopt. The one change I = think it needs is to account for when the time of the earlier date is in= the no-mans-land of a DST transition, and the end day is on a transitio= n day. e.g.=20 * X =3D 2020-03-06T02:30-08:00[America/Los_Angeles] * Y =3D 2020-03-08T03:15-07:00[America/Los_Angeles] If you try to use the Addition Path: * Let D =3D Y - X ignoring TZ =3D> P2D * Let I =3D X+D =3D> 2020-03-08T02:30 =3D> 2020-03-08T03:30-07:00[Ameri= ca/Los_Angeles] according to resolution rules, which is after Y. So I think that we just need to add an extra check at step (C): if you g= et an absolute time *after* the end time Y, subtract 1 day from the dura= tion and try again. e.g. * Let D =3D P2D - 1 day =3D> P1D * Let I =3D X+D =3D> 2020-03-07T02:30-08:00[America/Los_Angeles] * Let T =3D Y - X in absolute time =3D> PT23H45M * Result =3D D + T =3D> P1DT23H45M Neil. --c67f31cfdd564eb19720a3a21c0126ce Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 3 = Aug 2020, at 14:46, Justin Grant wrote:
Yep, agre= ed. This is a rare use case so it's definitely not worth a breaking chan= ge. Our goal is to find a deterministic, least-surprising solution for t= his weird case.  Ideally someone else would have already standardiz= ed how to handle this case and we could just adopt the standard, but so = far I haven't found it.

Does JSCalenda= r include any guidance about how to calculate durations from two date/ti= me+timezone (DATE-TIME - FORM #3) val= ues?  If not, would you be interested in collaborating with us to d= efine an algorithm that could be used by Temporal and included in the JS= Calendar spec? This may help with interop.

We don't have anything currently defined,= but I am interested in adding it; I agree it could be useful for intero= p.

Finally, could you explain what= you mean by "I think you would have to change the interpretation of = durations (Q1) in order to do anything different" ?

What I mean is that the addit= ion operation of a duration to a date is well defined, and we don't plan= to change it. Therefore, the =E2=80=9Ccorrectness=E2=80=9D of an algori= thm for calculating a duration between dates X and Y is constrained by t= he simple fact that the duration "D" that results must be such that X + = D =3D Y.

The Temporal case is further const= rained because you are representing both sets of dates in overlapping ti= me periods. Therefore to go back to the example you gave in the previous= email:

One probl= em is that the Addition Path and the Subtraction Path can return differe= nt results when an endpoint is in the "repeated hour" after DST ends in = the fall. For example, assume that X is 2020-10-31T01:30-07:00[America/L= os_Angeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "s= econd" 1:30AM on the day DST ends).  If we start from X, then we'd = add one nominal day to get 2020-11-01T01:30-07:00[America/Los_Angeles] (= the "first" 1:30AM), and then add one exact hour to get to the end. So t= he result is P1DT1H.  But if we start from Y, then subtracting one = nominal day from 2020-11-01T01:30-08:00[America/Los_Angeles] yields 2020= -10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So = the result is P1D.

As I said b= efore, both of these durations are arguably valid in RFC5545. However in= Temporal, the Subtraction one is not valid:
  • X =3D 2020= -10-31T01:30-07:00[America/Los_Angeles]
  • Y =3D 2020-11-01T01:= 30-08:00[America/Los_Angeles]
  • D =3D P1D (by the subtraction = method)
  • X + D =3D 2020-11-01T01:30-07:00[America/Los_Angeles= ] =E2=89=A0 Y

The "Addition" algorithm = however does produce the correct result, and I think is a reasonable bas= is for an algorithm to adopt. The one change I think it needs is to acco= unt for when the time of the earlier date is in the no-mans-land of a DS= T transition, and the end day is on a transition day. e.g.
  • X =3D 2020-03-06T02:30-08:00[America/Los_Angeles]
  • Y =3D= 2020-03-08T03:15-07:00[America/Los_Angeles]
    • If you tr= y to use the Addition Path:
    • Let D =3D Y - X ignoring TZ= =3D> P2D
    • Let I =3D X+D =3D> 2020-03-08T02:30 =3D= > 2020-03-08T03:30-07:00[America/Los_Angeles] according to resolution= rules, which is after Y.
    So I think that we just need= to add an extra check at step (C): if you get an absolute time after= the end time Y, subtract 1 day from the duration and try again. e.g= .
    • Let D =3D P2D - 1 day =3D> P1D
    • Let I =3D= X+D =3D> 2020-03-07T02:30-08:00[America/Los_Angeles]
    • Let= T =3D Y - X in absolute time =3D> PT23H45M
    • Result =3D D = + T =3D> P1DT23H45M

    Neil.
    <= div>
    --c67f31cfdd564eb19720a3a21c0126ce-- From nobody Mon Aug 3 23:22:05 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA643A0A66 for ; Thu, 30 Jul 2020 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dw1MlYt0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NuWLwcYA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQujBzhJNwMJ for ; Thu, 30 Jul 2020 18:49:14 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3744C3A0A53 for ; Thu, 30 Jul 2020 18:49:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 7EBBA580641; Thu, 30 Jul 2020 21:49:12 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Thu, 30 Jul 2020 21:49:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=mbhI Sbv0mYekLgH4YpuhqjwWfQg4pGhum5zmB4VW68M=; b=dw1MlYt01vGD9Ql/xD+U m5qXYRuEH4/5OxEzKMZrWm1wI7AkfcPgVTDrihfl6VGvQz6zWhZwLWzXJ7ex3mwI U9dsyHjXkRi9EJt2YXyj9m6vTz3XaZEzwAvR5AFSMB6ej776WYO3QaS3qFTlSl9q dT8wcKv0qnX0Grv/axhihHzEwJYIqOW6jGJNkhQmPaAvCQxUkRE7FKIVs49Tq2+o BZ1fmzRgZfORMyGEGVwKgSc+SChG/4sG+CxZhAiL6nRkNKQyozHax5sLqONWMBaP NYVyfRsCpmoUDIC3AV0z8JRc8Gm1i0/0WtoPfhVUUnR91IkeF/psbRE4SUhYMbXJ xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mbhISb v0mYekLgH4YpuhqjwWfQg4pGhum5zmB4VW68M=; b=NuWLwcYAgFnLfQApv4cuDk 8/CQAp2Ri9OqZ/W6G9UjyMn4J5DDysch8Ap8egUJw0SgRxH5+Fys0ksw2X3kAozC uPgYyHznTKeN+c0AINMBcblemCipM+D+ZxgFlRJEotSZjMLVpF6SC/pV0Xrkiw17 rL6/h49EDdQ+kDpJgBD72hYh75QLJlbI8EI4Wv1ErpvPIbAWQglVAp0lTb2KEtsJ kxlAIrqxEkjssdkvWkLFxCFhpsL7OJ2eiG4ANJVEYIXfLJ2UDsk6NACEOkxX4mM8 WuCmdh+wmHdIU1xNpzzKNrbuMpRz2/DuInZ0lOIzyOtbq2Xp986KzSj0uRZ9NgIQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieejgdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepgffgteeuheekudegieehkefghffguedvueejffeggefgleff udefveevfeekfeefnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgv ihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A47D1180558; Thu, 30 Jul 2020 21:49:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <70b795b8-6234-4073-982b-783b10cf3688@dogfood.fastmail.com> In-Reply-To: References: Date: Fri, 31 Jul 2020 11:49:10 +1000 From: "Neil Jenkins" To: "Justin Grant" , "Robert Stepanek" , "Bron Gondwana" , "Daniel Migault" , "Barry Leiba" , "Murray S. Kucherawy" , "barryleiba@gmail.com" , "Daniel Migault" Cc: "philip.chimento@gmail.com" , "Shane Carr" , "Philipp Dunkel" , "Daniel Ehrenberg" , calsify@ietf.org Content-Type: multipart/alternative; boundary=01e008b5a8974bbbbd5695e7dcf18bd7 Archived-At: X-Mailman-Approved-At: Mon, 03 Aug 2020 23:22:04 -0700 Subject: Re: [calsify] =?utf-8?q?RFC_5545/JSCalendar_questions_from_ECMAScrip?= =?utf-8?q?t_TC39_=22Temporal=22_working_group?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 01:49:17 -0000 --01e008b5a8974bbbbd5695e7dcf18bd7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 31 Jul 2020, at 05:10, Justin Grant wrote: > Hi JSCalendar team =E2=80=93 I=E2=80=99m part of the TC39 working grou= p that=E2=80=99s working on the Temporal proposal which will be the future date/time API for JavaScr= ipt. We=E2=80=99re planning to follow RFC 5545 for operations that add = or subtract durations from date/time values. But we have some questions= about how to interpret the iCalendar spec around edge cases when there=E2= =80=99s a DST transition during the added or subtracted duration. > [=E2=80=A6] > P.S. =E2=80=93 Apologies for contacting you individually via email ins= tead of via the public mailing list. I tried to join that list but never= heard back, so I=E2=80=99m falling back to old-school individual emails= . Hi Justin, I'm happy to answer some questions; your link was to the GitHub project = rather than a specific issue, but I'm presuming it's https://github.com/= tc39/proposal-temporal/issues/702 that you were referring to. I've copied this to the calsify (Calext WG) list , but encourage people to reply-all as you have = had difficulty joining it. In answer to the questions in that issue, my understanding is: Q1. As specified in RFC5545 (and JSCalendar): * A duration does not have a time zone associated with it. It is just a= n abstract number of weeks/days/hours etc. * If you want to determine how long in absolute terms a duration with d= ays/weeks is, this question only makes sense when you have a start date-= time to apply it to. * A duration may be added or subtracted from a date-time. If the date-t= ime does not have an associated time zone then this is very easy (it's j= ust like UTC: 1 day is always exactly 24h). * Otherwise, as per the spec, you would add the weeks/days first to the= calendar day/month/year. If the result is an ambiguous time due to DST,= you resolve at this point. Then you add the absolute hours/minutes/seco= nds etc. =E2=80=93 this cannot result in another ambiguity. There is onl= y ambiguity mapping from TZ -> UTC, not UTC -> TZ. I think your implementation in (1) seems similar to this, but I have not= looked at the source closely to confirm. I'm not sure why you think the= disambiguation in the middle is going to be problematic for users; sure= ly they generally won't notice where it happens? You just add the durati= on to the date-time and get a result. If I'm understanding it correctly, I do not think your proposed alternat= ive is acceptable because it applies the time component to the wall-cloc= k time, which means that if you had an event with duration PT1H that sta= rted on a 1-hour DST-transition point it would be translated into an abs= olute duration of 0 hours or 2 hours, which is clearly wrong! e.g. I hav= e an event that starts at 2019-03-31T02:45 in Europe/Berlin. I add a dur= ation of PT1H in wall clock time to get 2019-03-31T03:45 in Europe/Berli= n. However, those are the same time in UTC due to the DST transition, so= the absolute duration becomes 0! Q2. I don't think this issue arises when following the RFC5545 semantics= above. Q3. I don't think subtraction is well specified and probably wasn't deep= ly considered; it is basically only used for the offset of alerts before= the start of the event and I think your proposal of subtracting absolut= e components first is very reasonable for the reason you gave. We should= clarify this in the JSCalendar spec. Q4. This is really an implementation question. The result is clearly onl= y correct if you can add it to the start date and get back the end date = again with the already defined semantics. You can either: * Just find the difference in absolute time and represent this as a dur= ation in hours/minutes/seconds. * Subtract hours/minutes first to get the same wall clock time, then ca= lculate number of days difference to get a duration in weeks/days/hours/= minutes/seconds. Q5. I don't think I quite understand your question. You say you are "cal= culating differences between UTC values" but then the "difference ends i= nside a DST discontinuity" =E2=80=93 UTC doesn't have DST, so this doesn= 't make sense. Could you please clarify? Cheers, Neil. --01e008b5a8974bbbbd5695e7dcf18bd7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
    On Fr= i, 31 Jul 2020, at 05:10, Justin Grant wrote:

    Hi JSCalendar team =E2=80=93 I=E2=80=99m part of the TC39 w= orking group that=E2=80=99s working on the Temporal proposal which will be the future = date/time API for JavaScript.  We=E2=80=99re planning to follow RFC= 5545 for operations that add or subtract durations from date/time value= s.  But we have some questions about how to interpret the iCalendar spec around edge cases when there=E2= =80=99s a DST transition during the added or subtracted duration.

    [=E2=80=A6]

    P.S. =E2=80=93 Apol= ogies for contacting you individually via email instead of via the publi= c mailing list. I tried to join that list but never heard back, so I=E2=80= =99m falling back to old-school individual emails.


    Hi Justin,

    I= 'm happy to answer some questions; your link was to the GitHub project r= ather than a specific issue, but I'm presuming it's https://github.com/tc39/pro= posal-temporal/issues/702 that you were referring to.
    =
    I've copied this to the calsify (Calext WG) list, but encourage peo= ple to reply-all as you have had difficulty joining it.
    In answer to the questions in that issue, my understanding = is:

    Q1. As specified in RFC5545 (and JSCale= ndar):
    • A duration does not have a time zone associated = with it. It is just an abstract number of weeks/days/hours etc.
      • =
    • If you want to determine how long in absolute terms a duration with = days/weeks is, this question only makes sense when you have a start date= -time to apply it to.
    • A duration may be added or subtracted = from a date-time. If the date-time does not have an associated time zone= then this is very easy (it's just like UTC: 1 day is always exactly 24h= ).
    • Otherwise, as per the spec, you would add the weeks/days = first to the calendar day/month/year. If the result is an ambiguous time= due to DST, you resolve at this point. Then you add the absolute hours/= minutes/seconds etc. =E2=80=93 this cannot result in another ambiguity. = There is only ambiguity mapping from TZ -> UTC, not UTC -> TZ.
      =

    I think your implementation in (1) seems s= imilar to this, but I have not looked at the source closely to confirm. = I'm not sure why you think the disambiguation in the middle is going to = be problematic for users; surely they generally won't notice where it ha= ppens? You just add the duration to the date-time and get a result.
    <= /div>

    If I'm understanding it correctly, I do not thi= nk your proposed alternative is acceptable because it applies the time c= omponent to the wall-clock time, which means that if you had an event wi= th duration PT1H that started on a 1-hour DST-transition point it would = be translated into an absolute duration of 0 hours or 2 hours, which is = clearly wrong! e.g. I have an event that starts at 2019-03-31T02:45 in E= urope/Berlin. I add a duration of PT1H in wall clock time to get 2019-0= 3-31T03:45 in Europe/Berlin. However, those are the same time in UTC due= to the DST transition, so the absolute duration becomes 0!

    Q2. I don't think this issu= e arises when following the RFC5545 semantics above.

    <= /div>
    Q3. I don't think subtraction is well specified and probably w= asn't deeply considered; it is basically only used for the offset of ale= rts before the start of the event and I think your proposal of subtracti= ng absolute components first is very reasonable for the reason you gave.= We should clarify this in the JSCalendar spec.

    =
    Q4. This is really an implementation question. The result is clearl= y only correct if you can add it to the start date and get back the end = date again with the already defined semantics. You can either:
    =
    • Just find the difference in absolute time and represent this as = a duration in hours/minutes/seconds.
    • Subtract hours/minutes = first to get the same wall clock time, then calculate number of days dif= ference to get a duration in weeks/days/hours/minutes/seconds.
      • <= /ul>

      Q5. I don't think I quite understand your questi= on. You say you are "calculating differences between UTC values" but the= n the "difference ends inside a DST discontinuity" =E2=80=93 UTC doesn't= have DST, so this doesn't make sense. Could you please clarify?

      Cheers,
      Neil.
      --01e008b5a8974bbbbd5695e7dcf18bd7-- From nobody Tue Aug 4 07:54:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7593A00E5 for ; Tue, 4 Aug 2020 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYz0LGueptLz for ; Tue, 4 Aug 2020 07:54:17 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5003A003F for ; Tue, 4 Aug 2020 07:54:17 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id m7so6468988qki.12 for ; Tue, 04 Aug 2020 07:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=M/zcTSZTIpnifxyl5nRnKsoR5It3C7JdHKjL5GNBDSQ=; b=c7fdDAnx2l1bmbUubLxSlVpqFHMMQPquYU497EW8JT7rhdta9zYpJArBBSpzHyaw92 DC2iz1EoQBc+TxhCoW78NW7aPaBHfedsSY9rBPk6Jom6xM1UtOnnt3slswxs1+61U/1F rxNhFv8QUrL/NG9Xh9H3sT27YZePx7tKLm+3RVBS0vLlenfQ3taQZq5+zCFq2ZPF5q2L fm3nrgpD6cLEfW0dbPvbrgOlrZb+YeW08wCwppT9AfpbNRaQZv5ZsHxI893BVkdZ2qD0 BAz4hydlODbLd1q/5gLCIiR3iE7uk9p7IDxbKICMGDOWCZImfLeHxuidf6bfxfGLfvxt ofRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=M/zcTSZTIpnifxyl5nRnKsoR5It3C7JdHKjL5GNBDSQ=; b=AOKFcRxT4xfaKGxK/ONRiASEBTW5+YCuG5rgL0nEyuMC315deRQqHsYO94T+N5EMmT Q1TQyQ2l8CbO+DQ4RKkmX3znG+iIwgxbZHRNzb06+wAEhJqTx3VCusEgj/7qTuwIFHUG 4xWDJf6WJyJy0JpTUiaZ/xTiZ92ZjehluGMv5o6lLdFY3cCdzhiVEi6Z1Wzfo9DMQUPa L9dEmgHFb0I7Tgi+wKM8R9d2u2r2Exi7AYWubVMgz+L6rDH6SdJxvd8rx1OxRcQ7HNXt c2j0ZaE6CINHdWI1T0FKYGXCQWGOac2sfZcWKBeidr5GQpCPIH+wJaSy/VAjxuh9+n8R DkFg== X-Gm-Message-State: AOAM531qiqzZm7+Hnsmzc39WbaWycxSotPqKrKlZbMS8N5L02GkxiHGi jtOGcKHi7JeUdsFgsMZkAhoC6bySVAE= X-Google-Smtp-Source: ABdhPJzcy4lB51J470NgG5nh4jgYpkRfyPR7+cykuHpQE+NZldgy8LvD7Dffm5qCh9dj4YfUZlSGHQ== X-Received: by 2002:a37:4811:: with SMTP id v17mr22093493qka.166.1596552856342; Tue, 04 Aug 2020 07:54:16 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 94sm25754178qtc.88.2020.08.04.07.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 07:54:15 -0700 (PDT) To: Bron Gondwana , calsify@ietf.org References: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> From: Michael Douglass Message-ID: Date: Tue, 4 Aug 2020 10:54:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------03E30207F3182F849D411B92" Content-Language: en-US Archived-At: Subject: Re: [calsify] Review: draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 14:54:19 -0000 This is a multi-part message in MIME format. --------------03E30207F3182F849D411B92 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Bron. I'll try to get these incorporated today On 8/3/20 19:52, Bron Gondwana wrote: > Hi Mike, > > Thanks for uploading the latest ical relations.  Here's a quick review > of a couple of tiny changes needed! > > And I need you to confirm that there's no IPR that you're aware of :) > > Thanks, > > Bron. > > *REVIEW: > * > > *Abstract: > * > > nits complains: > > ** The abstract seems to contain references ([RFC5545]), which it > shouldn't. Please replace those with straight textual mentions of the > documents in question. > > Please change it not to be a reference in the Abstract (it's OK to > have a reference in the Introduction) > > *1.4 Link* > > See [I-D.daboo-caldav-attachments] > > Please update this reference to be RFC8607. > > *7.1. Concept* > > There's a bug in the example: > > SCONCEPT:http://example.com/event-types/sports > CONCEPT:http://example.com/event-types/arts/music > CONCEPT:http://example.com/task-types/delivery > > Please remove the leading 'S'! > > ... > > I think that's everything I can see :) > > Cheers, > > Bron. > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > --------------03E30207F3182F849D411B92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Thanks Bron.

      I'll try to get these incorporated today

      On 8/3/20 19:52, Bron Gondwana wrote:
      Hi Mike,

      Thanks for uploading the latest ical relations.  Here's a quick review of a couple of tiny changes needed!

      And I need you to confirm that there's no IPR that you're aware of :)

      Thanks,

      Bron.

      REVIEW:

      Abstract:

      nits complains:

        ** The abstract seems to contain references ([RFC5545]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

      Please change it not to be a reference in the Abstract (it's OK to have a reference in the Introduction)

      1.4 Link

          See [I-D.daboo-caldav-attachments]

      Please update this reference to be RFC8607.

      7.1. Concept

      There's a bug in the example:

           SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http://example.com/event-types/arts/music
     CONCEPT:http://example.com/task-types/delivery

      Please remove the leading 'S'!

      ...

      I think that's everything I can see :)

      Cheers,

      Bron.

      --
        Bron Gondwana, CEO, Fastmail Pty Ltd


      --------------03E30207F3182F849D411B92-- From nobody Tue Aug 4 23:36:55 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807703A1332 for ; Tue, 4 Aug 2020 23:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=gmQgDjTQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lGCu2odA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkIwx5W6CB5T for ; Tue, 4 Aug 2020 23:36:52 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020DB3A1331 for ; Tue, 4 Aug 2020 23:36:51 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4FFE75C00A2 for ; Wed, 5 Aug 2020 02:36:51 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 05 Aug 2020 02:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=ZyISauPoT0SMs+Iv1v2uGRaUauKDJw5VPTzjfEr vIh8=; b=gmQgDjTQKoENYfqCF6mpxM8mUO32hI7lONW2BBs1si7iuuUt+k5mNp1 hqZzV2iLeZAOM3aBEyNH9A76Or2XST4R170+azUZlUTEHHA8E0glXOM7L6mukIfE kAHPOPs/w4EYl2WjouB4uV5/RvjqYQMoAIdqOMZXxS/WitivhooStAxzPYi4kZIQ zdExv5xqZgVUHFopUOh1rAFMHs0jw13EXcrVHsbCgLDpf+sblgDSbVxlP7wXauTv s6XsDUJV+iVDDctcbO1S2rcZW8qz+IO+gVA+ioEpogGIN1iQy0v2i2bWXsodGPhE t2eO4zcnnYcy9zvUCoLekuIjwOBgu1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=ZyISauPoT0SMs+Iv1v2uGRaUauKDJ w5VPTzjfErvIh8=; b=lGCu2odAMsPm7Ld/Xgna1eCxLQoS8kkzaItg2E+FRLCW/ dGGG/NyaTGe4fjCZ5FNglDOGFQr7OLOs1LXDPbdXxjSO5I5ABtPBZhBSg9MUkqwP H62yfOKHNGgENdQd2Tg2PEnnVR/4iOUwCmLuVOtCj6dX384BDWugB4qRH676pwco aDgfafDCsNg1w6FOSTdFVV5KUAY8ZALFYs3RLyQV6XK2/f2GMaTj5+ZiRP3feK9q g8DkZZ1KM0dWtPRX+gRUdAj5iVBi62dWKL8iW8JqckmalBIcPdsbSxAf6LIZdPNV pZ08lWkgeqxebUVe3DyaqRDwCrhtgbYZrXtyYz5Hw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeejgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F254A1804C6; Wed, 5 Aug 2020 02:36:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-137-g55afb58-fm-20200804.001-g55afb586 Mime-Version: 1.0 Message-Id: <991b5bb8-fd48-48d5-81c9-2d07bd55acf7@dogfood.fastmail.com> Date: Wed, 05 Aug 2020 16:36:29 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=721cd17dfb854ecaa4760a0add1bc6fe Archived-At: Subject: [calsify] Minutes for IETF108 uploaded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 06:36:54 -0000 --721cd17dfb854ecaa4760a0add1bc6fe Content-Type: text/plain Hi All, The full minutes are uploaded to the datatracker here: https://datatracker.ietf.org/doc/minutes-108-calext/ These are the action points: *Me:** * ACTION: Bron to submit icalendar-relations to IESG once draft is refreshed. ACTION: Bron to make sure there's a milestone for icalendar-jscalendar mapping ACTION: Bron to update milestones *Daniel:** * ACTION: Daniel to do new WGLC for JSCalendar until August 15th. ACTION: Daniel to move VALARM draft forward. *Mike/Ken:** * I can't believe that I didn't capture any action points for Mike or Ken. I'm sure you have plenty to do. I appreciate your prompt attention to these actions. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --721cd17dfb854ecaa4760a0add1bc6fe Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      Hi All,
      The full minutes are uploaded = to the datatracker here:

      =

      <= div style=3D"font-family:Arial;">These are the action points:
      <= div style=3D"font-family:Arial;">
    Me:

    = ACTION: Bron to submit icalendar-relations to IESG once draft is refresh= ed.
    ACTION: Bron to make sure= there's a milestone for icalendar-jscalendar mapping
    ACTION: Bron to update milestones

    Daniel:

    ACTION: Daniel to do new WG= LC for JSCalendar until August 15th.
    ACTION: Daniel to move VALARM draft forward.

    M= ike/Ken:

    I can't believe that I didn't capture= any action points for Mike or Ken.  I'm sure you have plenty to do= .


    I appreciat= e your prompt attention to these actions.

    Cheers,

    Bron.

    --
      Bron Gondwana, CEO, Fast= mail Pty Ltd
      brong@fastmailteam.com
    <= br>

    --721cd17dfb854ecaa4760a0add1bc6fe-- From nobody Wed Aug 5 09:22:18 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2923C3A0C93 for ; Wed, 5 Aug 2020 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODMdXGKmZ9oL for ; Wed, 5 Aug 2020 09:22:15 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3593A0CC7 for ; Wed, 5 Aug 2020 09:22:15 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id d14so42174835qke.13 for ; Wed, 05 Aug 2020 09:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AL3qIV/u91QnFdz5fsTPGIDM2uNw7eALmXhKnzI/OoA=; b=AMZfFWbbhrdlRUccciRqbIApxLgtt9OecKwNu5fEgSyqBAxxbZy74ECnS6MlIex8c4 vjyHwd/OmfEabbmNvO0VvAlzrOX1H6LnH35yhg3kBzR4BsR/SMqM89EC01FqrQgh1/iE gg+dqxrR0F95O4apzCAZHxneN8p4fLm56MzTS9knMUARPhEdHbAv5OWfGFMRtEPBQLu7 0Q5JmIpZ70NdEnzGUQZH+AWIElkwBDAScuKG1h4G8lK+HuGL7R3ogbYy8+fu//I7BTwj rQWA5+M1XqDYNemGXjz/ooolneoqe5GloecTtERSntrJ31dLOpAR/sockt6Fi8lLCAEm /Y3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AL3qIV/u91QnFdz5fsTPGIDM2uNw7eALmXhKnzI/OoA=; b=MQTgH9uk1U8vnd3GJBYfdUn7m96e2AxIUuCwHAS5NP2vbqZRCOdR6mnmheaXRsomLQ 56S3BUagsTGBa55vdDqiO9p46gMUWTQg6c0PfU0lXVNdmL5IRnHygGF4va/mgP0xJtgV r6GFNkkxtcOD7G+/M1jw5W1h2WxA3EejiWOBvzs2GdBiOCEHz34bOVm4z1+ZnaxrDdm7 XW4sbKtE/tFYQbbQ0A9pFreLVzIduPunpnGPnxxRK4JWjRExMeZY+CS3mIqN92IiEixP SH79KK3BSWkiz3yR9TGc0l/UWbIA8IWnAZsG3299ZbLY7kYmpanry+Dx6sEV7fEtEJQX RYgg== X-Gm-Message-State: AOAM531KQZxlv32IoOFdVZZm80szJaE7pDJMMon4z5clEAhAxMj9GLU0 YV3J/JENx9MVPziHK1k5aMyUH1+p8ww= X-Google-Smtp-Source: ABdhPJxder9ovg9qLaepjAJI+I7X5Y3720UBXvVgh1qf+K9ykzNuZBnILte2Z52Mh48Y1Xlo8l3vTQ== X-Received: by 2002:a37:71c2:: with SMTP id m185mr4015260qkc.496.1596644534455; Wed, 05 Aug 2020 09:22:14 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id b23sm2433830qtp.41.2020.08.05.09.22.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 09:22:13 -0700 (PDT) To: Bron Gondwana , calsify@ietf.org References: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> From: Michael Douglass Message-ID: Date: Wed, 5 Aug 2020 12:22:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------00D7971B2ECCECBE8A2C24DE" Content-Language: en-US Archived-At: Subject: Re: [calsify] Review: draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:22:17 -0000 This is a multi-part message in MIME format. --------------00D7971B2ECCECBE8A2C24DE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/3/20 19:52, Bron Gondwana wrote: > Hi Mike, > > Thanks for uploading the latest ical relations.  Here's a quick review > of a couple of tiny changes needed! > > And I need you to confirm that there's no IPR that you're aware of :) I can confirm there is no IPR I'm aware of > > Thanks, > > Bron. > > *REVIEW: > * > > *Abstract: > * > > nits complains: > > ** The abstract seems to contain references ([RFC5545]), which it > shouldn't. Please replace those with straight textual mentions of the > documents in question. > > Please change it not to be a reference in the Abstract (it's OK to > have a reference in the Introduction) > > *1.4 Link* > > See [I-D.daboo-caldav-attachments] > > Please update this reference to be RFC8607. > > *7.1. Concept* > > There's a bug in the example: > > SCONCEPT:http://example.com/event-types/sports > CONCEPT:http://example.com/event-types/arts/music > CONCEPT:http://example.com/task-types/delivery > > Please remove the leading 'S'! > > ... > > I think that's everything I can see :) > > Cheers, > > Bron. > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > --------------00D7971B2ECCECBE8A2C24DE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    On 8/3/20 19:52, Bron Gondwana wrote:
    Hi Mike,

    Thanks for uploading the latest ical relations.  Here's a quick review of a couple of tiny changes needed!

    And I need you to confirm that there's no IPR that you're aware of :)
    I can confirm there is no IPR I'm aware of

    Thanks,

    Bron.

    REVIEW:

    Abstract:

    nits complains:

      ** The abstract seems to contain references ([RFC5545]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

    Please change it not to be a reference in the Abstract (it's OK to have a reference in the Introduction)

    1.4 Link

        See [I-D.daboo-caldav-attachments]

    Please update this reference to be RFC8607.

    7.1. Concept

    There's a bug in the example:

         SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http://example.com/event-types/arts/music
     CONCEPT:http://example.com/task-types/delivery

    Please remove the leading 'S'!

    ...

    I think that's everything I can see :)

    Cheers,

    Bron.

    --
      Bron Gondwana, CEO, Fastmail Pty Ltd


    --------------00D7971B2ECCECBE8A2C24DE-- From nobody Wed Aug 5 09:39:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578563A0ABB; Wed, 5 Aug 2020 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV5bpsAqeWfr; Wed, 5 Aug 2020 09:39:13 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974B43A0A9B; Wed, 5 Aug 2020 09:39:13 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id x142so6849180vke.0; Wed, 05 Aug 2020 09:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IJu+hHpSSfUv1s3oUFRtgUBep2kfkFhMLwldmxtf8m8=; b=oEPqc+ojgCbBV0ldklcdnEBfcf6w1OOPnbo3kkxhQz6gdymbur19TCFkaE4RbPET+R SKMPPXJjkdGrTC2p4pJNwZaJmZaDQW7wDHr7yqQO177kUGnPVc1tjJsPscLB3B71xRoW SouiVKu/ao62LozU95PLbnHQymMxQSBnHhOxEKcANKvHzabSCDVuRTJR4MhAmslDD1a+ pp+N1XBw7vct/lPH0/OdqS9+DeQUhMwDKpePkZ1fabYOdYYWaWEjLziFasYqFy7jNgl5 vdsKcToezIzoPDt8OkmV6+bQR4u1Iz6UeHZJDxkEp3tvdGkwZheBj77MZHWfBWG2JWzO a2bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IJu+hHpSSfUv1s3oUFRtgUBep2kfkFhMLwldmxtf8m8=; b=VtqPeN6CGxOmDbtTyIxlwsOH/yzOR9ug+3pEgmuW355ScXlgzPPKT2XodcM+a+YDcz ExNI3EWynU1bygNUSbsib3BtdyJd+I9H70irfAl7XZZeceWOwIWgE221yE+X/cOsJL9B RPJqDj03HL7AbgChvYdS3M72hxMcWYrDLLO73d7Oz/H/P21hNSQbJ7mdrgmdNqOy6d10 FOnvecn4Kk0JpWyhGTBVsRJIacPcpfOoPXHgc87UJIcnx0A9t0/uUEY4c44zVZ/+WqF5 WCCEh9xkMbsSAtOmEGOfEILPHycnPczoCiMnsKcgLidkP2Pg0PoCrhGJJDyyOrfukquR C2Lw== X-Gm-Message-State: AOAM532IC1dpK7a6rSemORpSFl8DkB6mg0X54JrE361W5kqQO/9PjRoQ lN4RVZIcC7xaCIJOr/mAWlE6XsX2WI7AyJbzAIAtcA== X-Google-Smtp-Source: ABdhPJwzEIWBWDVXQdbOyaVn9Dv0A9b5blfTAx285cCUZLqTa9vijOvzEnUJ1Q51q+YhU777jbHIPFr/tlYUfNX2vE4= X-Received: by 2002:a1f:d642:: with SMTP id n63mr3311767vkg.77.1596645552068; Wed, 05 Aug 2020 09:39:12 -0700 (PDT) MIME-Version: 1.0 References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> In-Reply-To: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> From: Daniel Migault Date: Wed, 5 Aug 2020 12:39:01 -0400 Message-ID: To: drip@ietf.org, curdle , IETF-Calsify , Ace Wg Content-Type: multipart/alternative; boundary="000000000000f69fe405ac2402a0" Archived-At: Subject: [calsify] Fwd: [108all] Final reminder: IETF 108 meeting survey X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:39:15 -0000 --000000000000f69fe405ac2402a0 Content-Type: text/plain; charset="UTF-8" Hi, Please consider - if not already done - to fill the IETf108 survey below. Yours, Daniel ---------- Forwarded message --------- From: IETF Executive Director Date: Wed, Aug 5, 2020 at 6:30 AM Subject: [108all] Final reminder: IETF 108 meeting survey To: <108all@ietf.org> Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance -- Jay Daley IETF Executive Director exec-director@ietf.org -- 108all mailing list 108all@ietf.org https://www.ietf.org/mailman/listinfo/108all -- Daniel Migault Ericsson --000000000000f69fe405ac2402a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi,=C2=A0

    Please consider - if not = already done - to fill the IETf108 survey below.=C2=A0

    =
    Yours,=C2=A0
    Daniel

    ---------- Forwarded message ---------
    F= rom: IETF Executive Directo= r <exec-director@ietf.org>
    Date: Wed, Aug 5, 2020 at 6:30 AM=
    Subject: [108all] Final reminder: IETF 108 meeting survey
    To: <<= a href=3D"mailto:108all@ietf.org">108all@ietf.org>


    = Thank you very much to the ~230 people who have filled in the IETF 108 meet= ing survey as this data is crucial to helping us plan future meetings.=C2= =A0 We could still use another 70 or so responses and so this is a final re= minder to please help us by taking a few minutes to complete the survey:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //www.surveymonkey.com/r/T3SL7JF

    Thanks in advance

    --
    Jay Daley
    IETF Executive Director
    exec-director@i= etf.org

    --
    108all mailing list
    108all@ietf.org https://www.ietf.org/mailman/listinfo/108all


    --
    Dani= el Migault
    Ericsson
    --000000000000f69fe405ac2402a0-- From nobody Thu Aug 6 23:17:30 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617433A03ED for ; Thu, 6 Aug 2020 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3f0aHyQ7Yjh for ; Thu, 6 Aug 2020 23:17:27 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB39D3A0141 for ; Thu, 6 Aug 2020 23:17:26 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id q4so428622edv.13 for ; Thu, 06 Aug 2020 23:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pd7NH+SOwZFcJyODxZgA+FD5IVlcHgWo3sx1VZ+L4Hk=; b=L5CozhJUGgNCx9OXu2BiMJpdD6U5RQb1okrAVUWxPBD2IbSMJmA9lgvL3DdMEYWTgL tXcetJP8KW2fid2kPM5e5bSPxVpiUurHb5qX6fSkI75uXpo8MFafP+1qoFjhMJWszRg3 Iht6A1V7qEWMWoX1oat5T15gKEXQ1I1MNCtrNj0lhL5w6zedPxQdnfU5264Z+RJa+b6y NX+OIInPgzXEawA9O1ns+lF32jJlujXtuFIGhOaqtDzcGydezCwdU/V99j+rP7JwlxMG Ydcl6MuvDQtdfOUAO5k5TyJHmA/7MWHNs/hjKYz927GhLKRHllREJDGzoGsc3W2nCzl1 PpOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pd7NH+SOwZFcJyODxZgA+FD5IVlcHgWo3sx1VZ+L4Hk=; b=AJLxj9auSbfHfPwWBj8uJpxNAbQ0puUT+a/Dc8Wwh7aqUgAKVaWQ/N+6GWofXwSrR5 P52ak/NO/SfUXvbEek2B260n0yKR1EBi/bwl1GbL431DGI5zc4vEkoUr32uzQgbCE1Kl yj8E5aIEUe/CnE1I+L8iT5wG7mj/evqzxrevQf1gDoJ2Ne3mZTm/H7i3SI6AkjUVS8aq whG/ruH5lJKbjoNxSZHcSPoR3qz/kdBGpIx7NwwIkFelVVsFBUgbvPtFFf3fFOpT5d0c ZOKugNoxk2lLJVNkL7H9XVKbXjm9LvmrenJJlPjGmeQdytgIh7L9c3S1SL2ITtDKmbtJ xIxA== X-Gm-Message-State: AOAM530rKdBG0Qi/Ca5HVcLbIvU+07PAlHrp3rIYBVpmsXzPZVuwmUyx 8vQ6/uWKq6noqDDlWejI3WVEGD+ag1BeH7p8ZnKyyQ== X-Google-Smtp-Source: ABdhPJxTvsI11Q64fD8Am+c7JFGYni4+IlWHgc1ttkRstQqKu1UH2DHdVN8hN4i7Lw4LFUgTHOfh35sg4NkQbpcfM0s= X-Received: by 2002:a50:ef04:: with SMTP id m4mr7555127eds.63.1596781045176; Thu, 06 Aug 2020 23:17:25 -0700 (PDT) MIME-Version: 1.0 References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> In-Reply-To: <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> From: Justin Grant Date: Thu, 6 Aug 2020 23:17:14 -0700 Message-ID: To: Neil Jenkins Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb5c7005ac438e8d" Archived-At: Subject: Re: [calsify] RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 06:17:28 -0000 --000000000000fb5c7005ac438e8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil - Apologies for slow response, I'm on vacation for a few days. At first glance your proposal above looks good to me but I'll need to review more closely without "vacation brain" when I get back next week. Cheers, Justin On Mon, Aug 3, 2020 at 8:34 PM Neil Jenkins wrote: > On Mon, 3 Aug 2020, at 14:46, Justin Grant wrote: > > Yep, agreed. This is a rare use case so it's definitely not worth a > breaking change. Our goal is to find a deterministic, least-surprising > solution for this weird case. Ideally someone else would have already > standardized how to handle this case and we could just adopt the standard= , > but so far I haven't found it. > > Does JSCalendar include any guidance about how to calculate durations fro= m > two date/time+timezone (DATE-TIME - FORM #3) values? If not, would you > be interested in collaborating with us to define an algorithm that could = be > used by Temporal and included in the JSCalendar spec? This may help with > interop. > > > We don't have anything currently defined, but I am interested in adding > it; I agree it could be useful for interop. > > Finally, could you explain what you mean by "*I think you would have to > change the interpretation of durations (Q1) in order to do anything > different"* ? > > > What I mean is that the addition operation of a duration to a date is wel= l > defined, and we don't plan to change it. Therefore, the =E2=80=9Ccorrectn= ess=E2=80=9D of an > algorithm for calculating a duration between dates X and Y is constrained > by the simple fact that the duration "D" that results must be such that X= + > D =3D Y. > > The Temporal case is further constrained because you are representing bot= h > sets of dates in overlapping time periods. Therefore to go back to the > example you gave in the previous email: > > One problem is that the Addition Path and the Subtraction Path can return > different results when an endpoint is in the "repeated hour" after DST en= ds > in the fall. For example, assume that X is > 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is > 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the d= ay > DST ends). If we start from X, then we'd add one nominal day to get > 2020-11-01T01:30-07:00[America/Los_Angeles] (the "first" 1:30AM), and the= n > add one exact hour to get to the end. So the result is P1DT1H. But if we > start from Y, then subtracting one nominal day from > 2020-11-01T01:30-08:00[America/Los_Angeles] yields > 2020-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. = So > the result is P1D. > > > As I said before, both of these durations are arguably valid in RFC5545. > However in Temporal, the Subtraction one is not valid: > > - X =3D 2020-10-31T01:30-07:00[America/Los_Angeles] > - Y =3D 2020-11-01T01:30-08:00[America/Los_Angeles] > - D =3D P1D (by the subtraction method) > - X + D =3D 2020-11-01T01:30-07:00[America/Los_Angeles] =E2=89=A0 Y > > > The "Addition" algorithm however does produce the correct result, and I > think is a reasonable basis for an algorithm to adopt. The one change I > think it needs is to account for when the time of the earlier date is in > the no-mans-land of a DST transition, and the end day is on a transition > day. e.g. > > - X =3D 2020-03-06T02:30-08:00[America/Los_Angeles] > - Y =3D 2020-03-08T03:15-07:00[America/Los_Angeles] > > If you try to use the Addition Path: > > - Let D =3D Y - X ignoring TZ =3D> P2D > - Let I =3D X+D =3D> 2020-03-08T02:30 =3D> > 2020-03-08T03:30-07:00[America/Los_Angeles] according to resolution ru= les, > which is after Y. > > So I think that we just need to add an extra check at step (C): if you ge= t > an absolute time *after* the end time Y, subtract 1 day from the duration > and try again. e.g. > > - Let D =3D P2D - 1 day =3D> P1D > - Let I =3D X+D =3D> 2020-03-07T02:30-08:00[America/Los_Angeles] > - Let T =3D Y - X in absolute time =3D> PT23H45M > - Result =3D D + T =3D> P1DT23H45M > > > Neil. > > --000000000000fb5c7005ac438e8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Neil - Apologies for slow=C2=A0response, I'm on vac= ation for a few days. At first=C2=A0glance your proposal above looks good= =C2=A0to me but I'll need to review more closely without=C2=A0"vac= ation brain" when I get back next week.=C2=A0

    Cheer= s,
    Justin


    On Mon, Aug 3, 2020 at 8:34 PM Neil= Jenkins <neilj@fastmailteam.c= om> wrote:
    Yep, agreed. This is a rare use case so it&#= 39;s definitely not worth a breaking change. Our goal is to find a determin= istic, least-surprising solution for this weird case.=C2=A0 Ideally someone= else would have already standardized how to handle this case and we could = just adopt the standard, but so far I haven't found it.
    <= div>
    Does JSCalendar include any guidance about how to calcul= ate durations from two date/time+timezone (DATE-TIME -=C2=A0FORM #3= ) values?=C2=A0 If not, would you be interested in collaborating with us to= define an algorithm that could be used by Temporal and included in the JSC= alendar spec? This may help with interop.

    We don't have anything currently defined, bu= t I am interested in adding it; I agree it could be useful for interop.
    =

    Finally, could you explain = what you mean by "I think you would have to change the interpretati= on of durations (Q1) in order to do anything different"=C2=A0?
    =

    What I mean is that the = addition operation of a duration to a date is well defined, and we don'= t plan to change it. Therefore, the =E2=80=9Ccorrectness=E2=80=9D of an alg= orithm for calculating a duration between dates X and Y is constrained by t= he simple fact that the duration "D" that results must be such th= at X + D =3D Y.

    The Temporal case is further c= onstrained because you are representing both sets of dates in overlapping t= ime periods. Therefore to go back to the example you gave in the previous e= mail:

    One problem is= that the Addition Path and the Subtraction Path can return different resul= ts when an endpoint is in the "repeated hour" after DST ends in t= he fall. For example, assume that X is 2020-10-31T01:30-07:00[America/Los_A= ngeles] and Y is 2020-11-01T01:30-08:00[America/Los_Angeles] (the "sec= ond" 1:30AM on the day DST ends).=C2=A0 If we start from X, then we= 9;d add one nominal day to get 2020-11-01T01:30-07:00[America/Los_Angeles] = (the "first" 1:30AM), and then add one exact hour to get to the e= nd. So the result is P1DT1H.=C2=A0 But if we start from Y, then subtracting= one nominal day from 2020-11-01T01:30-08:00[America/Los_Angeles] yields 20= 20-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder. So t= he result is P1D.

    As I said befor= e, both of these durations are arguably valid in RFC5545. However in Tempor= al, the Subtraction one is not valid:
    • X =3D 2020-10-31T01:= 30-07:00[America/Los_Angeles]
    • Y =3D 2020-11-01T01:30-08:00[Amer= ica/Los_Angeles]
    • D =3D P1D (by the subtraction method)
      • =
    • X + D =3D 2020-11-01T01:30-07:00[America/Los_Angeles] =E2=89=A0 Y

    The "Addition" algorithm however does= produce the correct result, and I think is a reasonable basis for an algor= ithm to adopt. The one change I think it needs is to account for when the t= ime of the earlier date is in the no-mans-land of a DST transition, and the= end day is on a transition day. e.g.
    • X =3D 2020-03-06T02= :30-08:00[America/Los_Angeles]
    • Y =3D 2020-03-08T03:15-07:00[Ame= rica/Los_Angeles]
    If you try to use the Addition Path:
    • Let D =3D Y - X ignoring TZ =3D> P2D
    • Let I = =3D X+D =3D>=C2=A02020-03-08T02:30 =3D> 2020-03-08T03:30-07:00[Americ= a/Los_Angeles] according to resolution rules, which is after Y.
      • So I think that we just need to add an extra check at step (C): if y= ou get an absolute time after the end time Y, subtract 1 day from th= e duration and try again. e.g.
      • Let D =3D P2D - 1 day =3D&g= t; P1D
      • Let I =3D X+D =3D> 2020-03-07T02:30-08:00[America/Los= _Angeles]
      • Let T =3D Y - X in absolute time =3D> PT23H45M
        =
      • Result =3D D + T =3D> P1DT23H45M

      Neil.

    --000000000000fb5c7005ac438e8d-- From nobody Sat Aug 15 12:16:35 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AF3A0B0C for ; Sat, 15 Aug 2020 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoAsr5Op6NWu for ; Sat, 15 Aug 2020 12:16:31 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC513A0995 for ; Sat, 15 Aug 2020 12:16:31 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id bo3so13313743ejb.11 for ; Sat, 15 Aug 2020 12:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dU1FVdeJ8VeE4FfsgBWI6RbPGnbXZto1Tu2rfk7WOfk=; b=dY2R4uhBNfE5rpMSicolJY5NxOs4jFlcuaCB1ZK+lj/11NYVLb7urp7y2LNW2+TAU7 Jlmu8LyjqzD2xy7UAEZIPtap7vgedrcoC1Z9roFTXIhkBBqNY/WGVfZ2LmIGK0dcslLK q+0tB/eRH44xFq/Qz/bOUke/mxqJ49fTeLIhKddgxThI9BrEzbhh4XIUH3tNIKyc9Md8 mRfNl7betAa4VrY/M+xaNokYGXFuAa1wIUV+Qbo2cgx13BMlu2PvFQPZnZvGW3n8rGm1 tp9sqh0Pep0R1fshIxnTo+xJiLMjmq1wfGXYjqn6eKvoypBqYwk3EuR0vTXxvc/Pth5K kUCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dU1FVdeJ8VeE4FfsgBWI6RbPGnbXZto1Tu2rfk7WOfk=; b=rL2IwJOlh8j+j1e+r3upESeQuLbsR3iTo3N3uIZm3t3KDN4S80x2T/EFiRF8oqdAB1 680g1TwelLLKgP7XoGKMT+mHpk3T29kvtQSwPKyZjJQeNDJFJ790a4ajx/qAE4XcZSgx 7ywkne73Ct7L25Wb3oALqJmNXeDdSFuVfGUuEilgbsgvgkQBLAO6LyNW/SYhhpJgSedA 9Zp04gfrlw4VuM0AX0qyi9BKY9pOwHOm+D/jZ68kpZIy2gOJlwsdujWPaM8vREkaWmYr niomC9hcGG4ATXOC8tj5/u2xe7A9hZJSn10Dsb6rRWsjc43XSfn+REy6hXCaFNwZfq/M yoOA== X-Gm-Message-State: AOAM531Fvdi8hnLZgVMwFZdvKbJJZAMvk3diW2/SYcWpx2PORjFQtf/J l1tCV5Z53hp1JiPREqhvgH5WSq31NhgiQx5u4MOfi7SJQGA= X-Google-Smtp-Source: ABdhPJzEKbqVc0bx8/iPWmjZcgz1xynR8erZfMoC+asoJxAeSQNLPMWr2gfj3GpLB0STJPXyAucf78LyW3BFpHwMYmA= X-Received: by 2002:a17:906:7c4f:: with SMTP id g15mr7898503ejp.82.1597518989916; Sat, 15 Aug 2020 12:16:29 -0700 (PDT) MIME-Version: 1.0 References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> In-Reply-To: From: Justin Grant Date: Sat, 15 Aug 2020 12:16:19 -0700 Message-ID: To: Neil Jenkins Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000ea7c9e05acef5fdb" Archived-At: Subject: Re: [calsify] RFC 5545/JSCalendar questions from ECMAScript TC39 "Temporal" working group X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:16:33 -0000 --000000000000ea7c9e05acef5fdb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil - reviewing this now. Had a quick question: > Let T =3D Y - X in absolute time =3D> PT23H45M Why is X used here instead of I? Here's what I would have expected: Let T =3D Y - *I* in absolute time =3D> PT23H45M On Thu, Aug 6, 2020 at 11:17 PM Justin Grant < justingrant.ietf.public@gmail.com> wrote: > Hi Neil - Apologies for slow response, I'm on vacation for a few days. At > first glance your proposal above looks good to me but I'll need to review > more closely without "vacation brain" when I get back next week. > > Cheers, > Justin > > > On Mon, Aug 3, 2020 at 8:34 PM Neil Jenkins > wrote: > >> On Mon, 3 Aug 2020, at 14:46, Justin Grant wrote: >> >> Yep, agreed. This is a rare use case so it's definitely not worth a >> breaking change. Our goal is to find a deterministic, least-surprising >> solution for this weird case. Ideally someone else would have already >> standardized how to handle this case and we could just adopt the standar= d, >> but so far I haven't found it. >> >> Does JSCalendar include any guidance about how to calculate durations >> from two date/time+timezone (DATE-TIME - FORM #3) values? If not, would >> you be interested in collaborating with us to define an algorithm that >> could be used by Temporal and included in the JSCalendar spec? This may >> help with interop. >> >> >> We don't have anything currently defined, but I am interested in adding >> it; I agree it could be useful for interop. >> >> Finally, could you explain what you mean by "*I think you would have to >> change the interpretation of durations (Q1) in order to do anything >> different"* ? >> >> >> What I mean is that the addition operation of a duration to a date is >> well defined, and we don't plan to change it. Therefore, the =E2=80=9Cco= rrectness=E2=80=9D >> of an algorithm for calculating a duration between dates X and Y is >> constrained by the simple fact that the duration "D" that results must b= e >> such that X + D =3D Y. >> >> The Temporal case is further constrained because you are representing >> both sets of dates in overlapping time periods. Therefore to go back to = the >> example you gave in the previous email: >> >> One problem is that the Addition Path and the Subtraction Path can retur= n >> different results when an endpoint is in the "repeated hour" after DST e= nds >> in the fall. For example, assume that X is >> 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is >> 2020-11-01T01:30-08:00[America/Los_Angeles] (the "second" 1:30AM on the = day >> DST ends). If we start from X, then we'd add one nominal day to get >> 2020-11-01T01:30-07:00[America/Los_Angeles] (the "first" 1:30AM), and th= en >> add one exact hour to get to the end. So the result is P1DT1H. But if w= e >> start from Y, then subtracting one nominal day from >> 2020-11-01T01:30-08:00[America/Los_Angeles] yields >> 2020-10-31T01:30-07:00[America/Los_Angeles]. There is no time remainder.= So >> the result is P1D. >> >> >> As I said before, both of these durations are arguably valid in RFC5545. >> However in Temporal, the Subtraction one is not valid: >> >> - X =3D 2020-10-31T01:30-07:00[America/Los_Angeles] >> - Y =3D 2020-11-01T01:30-08:00[America/Los_Angeles] >> - D =3D P1D (by the subtraction method) >> - X + D =3D 2020-11-01T01:30-07:00[America/Los_Angeles] =E2=89=A0 Y >> >> >> The "Addition" algorithm however does produce the correct result, and I >> think is a reasonable basis for an algorithm to adopt. The one change I >> think it needs is to account for when the time of the earlier date is in >> the no-mans-land of a DST transition, and the end day is on a transition >> day. e.g. >> >> - X =3D 2020-03-06T02:30-08:00[America/Los_Angeles] >> - Y =3D 2020-03-08T03:15-07:00[America/Los_Angeles] >> >> If you try to use the Addition Path: >> >> - Let D =3D Y - X ignoring TZ =3D> P2D >> - Let I =3D X+D =3D> 2020-03-08T02:30 =3D> >> 2020-03-08T03:30-07:00[America/Los_Angeles] according to resolution r= ules, >> which is after Y. >> >> So I think that we just need to add an extra check at step (C): if you >> get an absolute time *after* the end time Y, subtract 1 day from the >> duration and try again. e.g. >> >> - Let D =3D P2D - 1 day =3D> P1D >> - Let I =3D X+D =3D> 2020-03-07T02:30-08:00[America/Los_Angeles] >> - Let T =3D Y - X in absolute time =3D> PT23H45M >> - Result =3D D + T =3D> P1DT23H45M >> >> >> Neil. >> >> --000000000000ea7c9e05acef5fdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Neil - reviewing this now. Had a quick question:=C2=A0<= div>
    > Let T =3D Y - X in absolute time =3D> PT23H45M

    Why is X used here instead of I?=C2=A0 Here's w= hat I would have expected:=C2=A0=C2=A0

    Let T =3D Y= - I in absolute time=C2=A0 =3D> PT23H45M

    On Thu, Aug 6, 202= 0 at 11:17 PM Justin Grant <justingrant.ietf.public@gmail.com> wrote:
    Hi Neil - Apolog= ies for slow=C2=A0response, I'm on vacation for a few days. At first=C2= =A0glance your proposal above looks good=C2=A0to me but I'll need to re= view more closely without=C2=A0"vacation brain" when I get back n= ext week.=C2=A0

    Cheers,
    Justin

    <= /div>

    On Mon, Aug 3, 2020 at 8:34 PM Neil Jenkins <neilj@fastmailteam.com> wrote:=
    On Mon, 3 Aug 2020, at 14:46, Justin Grant wrote:
    Yep, agreed. This is a rare use cas= e so it's definitely not worth a breaking change. Our goal is to find a= deterministic, least-surprising solution for this weird case.=C2=A0 Ideall= y someone else would have already standardized how to handle this case and = we could just adopt the standard, but so far I haven't found it.

    Does JSCalendar include any guidance about how = to calculate durations from two date/time+timezone (DATE-TIME -=C2=A0FORM #3) values?=C2=A0 If not, would you be interested in collaborating w= ith us to define an algorithm that could be used by Temporal and included i= n the JSCalendar spec? This may help with interop.

    We don't have anything currently de= fined, but I am interested in adding it; I agree it could be useful for int= erop.

    Finally, could you explain what you mean by "I think you w= ould have to change the interpretation of durations (Q1) in order to do any= thing different"=C2=A0?
    What I mean is that the addition operation of a duration to a d= ate is well defined, and we don't plan to change it. Therefore, the =E2= =80=9Ccorrectness=E2=80=9D of an algorithm for calculating a duration betwe= en dates X and Y is constrained by the simple fact that the duration "= D" that results must be such that X + D =3D Y.

    The Temporal case is further constrained because you are representing= both sets of dates in overlapping time periods. Therefore to go back to th= e example you gave in the previous email:

    One problem is that the Addition Path and the Subtrac= tion Path can return different results when an endpoint is in the "rep= eated hour" after DST ends in the fall. For example, assume that X is = 2020-10-31T01:30-07:00[America/Los_Angeles] and Y is 2020-11-01T01:30-08:00= [America/Los_Angeles] (the "second" 1:30AM on the day DST ends).= =C2=A0 If we start from X, then we'd add one nominal day to get 2020-11= -01T01:30-07:00[America/Los_Angeles] (the "first" 1:30AM), and th= en add one exact hour to get to the end. So the result is P1DT1H.=C2=A0 But= if we start from Y, then subtracting one nominal day from 2020-11-01T01:30= -08:00[America/Los_Angeles] yields 2020-10-31T01:30-07:00[America/Los_Angel= es]. There is no time remainder. So the result is P1D.

    As I said before, both of these durations are arguabl= y valid in RFC5545. However in Temporal, the Subtraction one is not valid:<= br>
    • X =3D 2020-10-31T01:30-07:00[America/Los_Angeles]
      • =
    • Y =3D 2020-11-01T01:30-08:00[America/Los_Angeles]
    • D =3D P1D= (by the subtraction method)
    • X + D =3D 2020-11-01T01:30-07:00[A= merica/Los_Angeles] =E2=89=A0 Y

    The "= Addition" algorithm however does produce the correct result, and I thi= nk is a reasonable basis for an algorithm to adopt. The one change I think = it needs is to account for when the time of the earlier date is in the no-m= ans-land of a DST transition, and the end day is on a transition day. e.g. =
    • X =3D 2020-03-06T02:30-08:00[America/Los_Angeles]
    • Y =3D 2020-03-08T03:15-07:00[America/Los_Angeles]
    If= you try to use the Addition Path:
    • Let D =3D Y - X ignorin= g TZ =3D> P2D
    • Let I =3D X+D =3D>=C2=A02020-03-08T02:30 = =3D> 2020-03-08T03:30-07:00[America/Los_Angeles] according to resolution= rules, which is after Y.
    So I think that we just need to= add an extra check at step (C): if you get an absolute time after t= he end time Y, subtract 1 day from the duration and try again. e.g.
    • Let D =3D P2D - 1 day =3D> P1D
    • Let I =3D X+D =3D&g= t; 2020-03-07T02:30-08:00[America/Los_Angeles]
    • Let T =3D Y - X = in absolute time =3D> PT23H45M
    • Result =3D D + T =3D> P1DT= 23H45M

    Neil.

    --000000000000ea7c9e05acef5fdb-- From nobody Sun Aug 16 16:39:40 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130FD3A0A86 for ; Sun, 16 Aug 2020 16:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OPIPeIbh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i45gO/2z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuB3OyVfd4jc for ; Sun, 16 Aug 2020 16:39:38 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC51B3A0A8F for ; Sun, 16 Aug 2020 16:39:37 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 015F01883; Sun, 16 Aug 2020 19:39:36 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 16 Aug 2020 19:39:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=cf+7 YQ7wNVWVE4ZSCtXVWCbsPIhUdD9YQqhTB+et1B8=; b=OPIPeIbh2Ds6CrN4XCEC d1TkYQxkBEbYLo32RTT7ie3BfgcFkfZdhJsat4Zmb+1JMExFXcH/ZjiPf9BfpwtD goOUxrI+gj66nV92ZmhW8+wQfspvLDHl+YpkTHj+DCMv1DzLwGTyySmotJ+fZp4W IZvMGJ/MVdXLsCpL+wm+0b2CCc7fWJOfCAb+DzbB85yN5PmUbHgV1cGXmecmjmvh Eiq+5F+bIBKG4BeorJKS6tqKop/ibUKXrBSKjQbpZDpl9Bed2MBEApMrtwMCgxDg ltaFah9N9kYRtv9C8GPW7NxwFytGWuHN6TGpxT9YrXlysHQjTNr/AUoPR7Dnl+4j ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cf+7YQ 7wNVWVE4ZSCtXVWCbsPIhUdD9YQqhTB+et1B8=; b=i45gO/2zvPe3sa8QtV5Y1q u6lvQ5mh1MA8pzm/Q60WAmJbrSQkEaTsdH5IcpabGxAchFeTpZWL9IB46ch/+ZDd UiMZ6BAIAlO2fXGwAIVMJAT+2NxPE7bvMcaWyZ8UqTfDTqnIJcrihC0cq2OX5bBU 5NGGEBhVo54s+Px8jrShvQ2s9SsZHz0kdPwTVMMEYIETUmOcjYNMklYSlwYslPJd do7HCamFmnyMZeUFUhrmQN4CZEITl1xhjAFGjbb7W+BQDMPAlts+BF8b7az460Uz 0Trgiu4/HySs7O/XWysyDlW7no7S1usp3qceq/4dUxbJEICvffnz7+DFMaTtJTcQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtvddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeuhfdujedtie evkedvhfffgfelfeelhfefkeehhfekleekhfefueefveffjeeinecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B6A3180169; Sun, 16 Aug 2020 19:39:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-185-g038a4a3-fm-20200813.001-g038a4a3b Mime-Version: 1.0 Message-Id: In-Reply-To: References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> Date: Mon, 17 Aug 2020 09:39:35 +1000 From: "Neil Jenkins" To: "Justin Grant" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=38c8da1f633b456f8ca58c4f6e17a7eb Archived-At: Subject: Re: [calsify] =?utf-8?q?RFC_5545/JSCalendar_questions_from_ECMAScrip?= =?utf-8?q?t_TC39_=22Temporal=22_working_group?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 23:39:39 -0000 --38c8da1f633b456f8ca58c4f6e17a7eb Content-Type: text/plain On Sun, 16 Aug 2020, at 05:16, Justin Grant wrote: > Hi Neil - reviewing this now. Had a quick question: > > > Let T = Y - X in absolute time => PT23H45M > > Why is X used here instead of I? Here's what I would have expected: > > Let T = Y - *I* in absolute time => PT23H45M Correct. This was an error, it should be *`I`* as you say. Neil. --38c8da1f633b456f8ca58c4f6e17a7eb Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Sun, 16 Aug = 2020, at 05:16, Justin Grant wrote:
    Hi Neil - reviewing this now. = Had a quick question: 

    > Let T =3D = Y - X in absolute time =3D> PT23H45M

    Why= is X used here instead of I?  Here's what I would have expected:&n= bsp; 

    Let T =3D Y - I in absolu= te time  =3D> PT23H45M

    Correct. This was an error, it should be I as you say.

    Neil.
    --38c8da1f633b456f8ca58c4f6e17a7eb-- From nobody Tue Aug 18 21:38:25 2020 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BC03A117C; Tue, 18 Aug 2020 21:38:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159781190336.13846.14000678722624250848@ietfa.amsl.com> Date: Tue, 18 Aug 2020 21:38:23 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-29.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 04:38:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-29.txt Pages : 82 Date : 2020-08-18 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-29 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 18 21:47:52 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA32E3A0FE2 for ; Tue, 18 Aug 2020 21:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tSD2Upj/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IMy9iyYl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSsDh8w2ckXo for ; Tue, 18 Aug 2020 21:47:49 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8081F3A0E91 for ; Tue, 18 Aug 2020 21:47:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DF234BE6 for ; Wed, 19 Aug 2020 00:47:48 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 19 Aug 2020 00:47:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=SPxVlI0 0HrlHD30x4pLdOV/ZVkG/sLl797OoEFcj56Q=; b=tSD2Upj/fktoL5BKDadY7mc XU+bAL0PwV4LHM9xW0BM/UIBMQL4Pw2ECFbxgsGAeZeIYOSQGNdDTYbQblgVE19B ExD+/uXTP8PXSe74KczzGPo2Zkh0xoFZ7gzzOPUAy3/QkghI2EXGrBu8c6jjUf9N ohiE1hrwDKJo3tn5/30/IcU20emUPH3LrICQhSv7SnUZdK5/LAffAEXDS4G/X7vK emoSKe2yypeBwg3gdN8vo+8O8KoR+jdtc7X0e8Vol/p68hhGLzAZlMghVk2mFH7z IRhG5jHTq6Tbei+lT04Z/h19TZqLoNR80fC8ab1dwN1+0Zdp1sXPwYo21bapIFw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SPxVlI 00HrlHD30x4pLdOV/ZVkG/sLl797OoEFcj56Q=; b=IMy9iyYlfkL6uytW/a6sbk 7C+s9Z174QOs2KJQIcLV7wJe0MebApTzd74CHEaxIe/s5vuSkzo6UI+6IypnaOEY V3Byf0woGgLeo8PxiHejGh4skGkiWdBrK2CRKp4VOdUa0oj4Vl1dIq9mLpaYUsat p9AgoIJJoy+7r/NKJCLHemSnl/+O4Tp+3jZguQmyGaRIlvX2SQ20I4DgFou2V07N r4WHJRr7yttW90lLeUPanTFTjKHOKb2pb5o7GAKAhLObJBpOjSKh6k9LjMMU+HcA oERO+o5KHfMSKwTiUuOsv36Vw1HGeMSfiFHNwjAxDGdqbZZK2T2xbxgfCKE48dXA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtjedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 563F118014A; Wed, 19 Aug 2020 00:47:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-191-gef79d59-fm-20200818.001-gef79d590 Mime-Version: 1.0 Message-Id: <0e6de35a-39f0-4676-b2d2-c92d33747155@dogfood.fastmail.com> In-Reply-To: <159781190336.13846.14000678722624250848@ietfa.amsl.com> References: <159781190336.13846.14000678722624250848@ietfa.amsl.com> Date: Wed, 19 Aug 2020 14:47:36 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a2ad3bb310ba4a1494068855edf661e2 Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-29.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 04:47:51 -0000 --a2ad3bb310ba4a1494068855edf661e2 Content-Type: text/plain With last (for real this time) call over, this incorporates the small amount of further feedback I received. Quick summary of changes: * Document the semantics of dates/durations with DST: this is intended to match iCalendar (where it is poorly specified) and what existing implementations do. * Allow weeks to be combined with other duration components (as per the revision to ISO8601 last year). * Change the delimiter for custom props: the forward slash is awkward as it's a control character in JSON pointer so I've changed it to be a colon instead. Neil. --a2ad3bb310ba4a1494068855edf661e2 Content-Type: text/html
    With last (for real this time) call over, this incorporates the small amount of further feedback I received. Quick summary of changes:
    • Document the semantics of dates/durations with DST: this is intended to match iCalendar (where it is poorly specified) and what existing implementations do.
    • Allow weeks to be combined with other duration components (as per the revision to ISO8601 last year).
    • Change the delimiter for custom props: the forward slash is awkward as it's a control character in JSON pointer so I've changed it to be a colon instead.
    Neil.
    --a2ad3bb310ba4a1494068855edf661e2-- From nobody Sat Aug 22 21:19:32 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B93A1110 for ; Sat, 22 Aug 2020 21:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljnc-2G_b2ZN for ; Sat, 22 Aug 2020 21:19:29 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284EF3A110E for ; Sat, 22 Aug 2020 21:19:29 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id cs12so2397924qvb.2 for ; Sat, 22 Aug 2020 21:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=eSK8Yhhhn1HWRREIVS8RD8WI5qUglK5+VfcWQk7jVL0=; b=qjygeyEB0VMzE8i1Vn7Bpg1xy/Gxe5YyrHGhDcYCNog14sYrp40r34Vz5N6MJMa7Rd eRMivgX2NQfoagGNJlYEPvNy0rnGSVTuTIu/ofLCFY7ma9U424UPOyTUHl/JPpXInLKp Ep80VNz9qgzoggipzyHEH1wHfNyoWgqVid0EC9Z0oTDq43x2IdFPPGLHdIahUvp7F985 2B8mnaGSBy1PFU+Gc3vr81sfkoL/80N9NtSMBgn91eIz2SmBiavzwhk8fzFvj8mp0VhG BZhN54qOz2S1aRct3eIfPN69KaTBdZ0ermr0zH3E2bFZ1gtE0rjr1DI3dAPgG2eBUe1N yEYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=eSK8Yhhhn1HWRREIVS8RD8WI5qUglK5+VfcWQk7jVL0=; b=tENG9zBmnUh4p12LGKj99g81KJWr8Jq91vrSVzte4bcdQFuOn+XNw4q5QKCtwR3EG0 oZY4EurFYXThKga/DEIyFLhlWyqoca3/STdp9ZgyZo0fNvxBJNAxDCNWiAWDOvCUwgWi ZSh0+Y/4r9PpnGpAJPQgxd9G11rhfz4/jvOZdeY/1upZ8YiWp3eJhhscpoBAo1BTqlUi Gsvr3/Okvay2S7fnSpast7ipUEtVXZ4SIcC8XG+idTQv9zkJd/i+GuX6iiTOmnEaBl4Y EWJddXDUI3CKr/x1gXDorLj51TmxDSgr0ad39+CbZ+mOCrfC/W7NZIKhg0lHG+3827wV YhHQ== X-Gm-Message-State: AOAM5310jMN/B85TMiAtsTZamzZq6poeGlBr3Fb5/t9LLKhopZKssVmB TqHv0n0QwQxTRDzNdrRh6WjvbrrEAiDNMg== X-Google-Smtp-Source: ABdhPJwcUTQmEfIQyHk5V9m8baBMx5VMSfUZ4taiaUi/gWYYDVTiKg+kqPEA44BzMnJPDoe3qc3ucw== X-Received: by 2002:a05:6214:2a4:: with SMTP id m4mr291148qvv.120.1598156367875; Sat, 22 Aug 2020 21:19:27 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id b23sm7580226qtp.41.2020.08.22.21.19.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Aug 2020 21:19:27 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> Date: Sun, 23 Aug 2020 00:19:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 04:19:31 -0000 I find the explanations about recurrenceId a little confusing. To be or not to be... When is it valid to actually have a recurrenceId property and if it exists what are the constraints? It looks like it should never appear anywhere for a full calendar object with master and overrides. It MUST appear in a 'detached' instance which represents a single override - for example being invited to a single instance. Or - we could say it MAY appear in the override but its value MUST be the same as the key. On timezones in overrides I haven't found anything in 5545 that says the tzid MUST be the tzid in the master dtstart. Is it valid to have a recurrenceid with a different timezone? I would suggest it shouldn't be. As it relates to jscalendar: The override keys are the local date time as calculated based on the master start using the master timezone. What happens if an override changes the timezone? We can't use the recurrenceId value as that's the local time in the master timezone. In iCalendar it's easy (I think). The recurrenceId timezone is distinct from the dtstart timezone so if I want one instyance of my meeting in London instead of New York I can easily override it. An example in jscalendar would help (me). From nobody Sun Aug 23 15:37:42 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0803A0EBD for ; Sun, 23 Aug 2020 15:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shqkgBRAg1Kf for ; Sun, 23 Aug 2020 15:37:39 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF2E3A0EBC for ; Sun, 23 Aug 2020 15:37:38 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id 144so5921424qkl.5 for ; Sun, 23 Aug 2020 15:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=gEYrR0zO+G9gvVhqlZ5YzvMQ5KavXY06xRSUfa8WS8M=; b=JFwpPw06wmu5VV8r56QOGWakDD3z96UTdREQ0UTxXbiZzMBBFmP57FzdM0UgrJ1/KF xsn+UEIyIXzQfBvnCCSRi6Kkybb0dqR5y6f9h00r6uImBjUI4NncWbU4YaGCb3kI7pfy aObLpl25LL1S9afkIda1hELXRV3x/5Ll1EssByIRUhwAzLRqfW3IbnCCZW3WRDwftQSd 0oOBa/f2RNfprnGhHOk519FI5XXrHDOJK121DGQG4dAlw92tPdS4dLsscHVVTH21Epz8 /P0AI8k7SGptcReAHKOQuRGFpQdfRexSZp8ZtD2Tf4r1xcJkR8XdJLZHHqwfhsl9e5m2 eoog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gEYrR0zO+G9gvVhqlZ5YzvMQ5KavXY06xRSUfa8WS8M=; b=cMtG1fwR3XIwHE8uhFSbmmfED99dv9ZnUyCXdxOTnVQUA4UUZLVh2J/em2+Ogv6IMV /zefQwDRghW339tLfBwo+Y7gSeWCldzm+NmdV4KJ115PH90MUxf/WlbTE7MwmoZnV/OR vR19Ud1Y5XohpkW3jIONQlFXu7kORG9Ik8kOy/lT3wNkG22QoLdxprMIBUPIpHitjRjv B7tk5xH7UqB1L9cvZd90QmBkfy0L5pSh1eBNFt0aEN1SV2l8wpoHe5rTKVJMaWTygFyA 3ScPfjSf/LD3msLrK3CWvC06rVUTsw+HkOApUYjUOcn/qysuDmAe7us+H+i1LDJFWmlG mFng== X-Gm-Message-State: AOAM532p5564QaYVMhUj5N+v8ri2ctyouPSovljsEIDpYWUlabBia+EG WZSqhtaxjKv6BHbTtZa3TBKOIbJb/YvPNw== X-Google-Smtp-Source: ABdhPJw1WyGW3sRVnwn4ppTiYSMU2UCXNBC4tZ/A7vknrsywNv5Ghu0ZSem0mNvxNueCpyIguBOfdg== X-Received: by 2002:a05:620a:712:: with SMTP id 18mr2206604qkc.160.1598222257450; Sun, 23 Aug 2020 15:37:37 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id e61sm9497167qtd.20.2020.08.23.15.37.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 15:37:36 -0700 (PDT) From: Michael Douglass To: Calsify References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> Message-ID: Date: Sun, 23 Aug 2020 18:37:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> Content-Type: multipart/alternative; boundary="------------4FCCF847FBA5F57B3C63CB5B" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 22:37:41 -0000 This is a multi-part message in MIME format. --------------4FCCF847FBA5F57B3C63CB5B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This is an example of where I have difficulties: BEGIN:VEVENT DTEND;TZID=Europe/London:20200827T130000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7 A@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200827T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T221349Z DTSTART;TZID=Europe/London:20200827T120000 CREATED:20200823T221135Z ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA T=NEEDS-ACTION:mailto:mdouglass@bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT When that's converted to jscalendar we will have a recurrence id based on "America/New_York"- which won't appear anywhere - and a start time based on "Europe/London". That might work sort of - the recurrenceid in this case could be treated just as a key. But what if that gets sent out as jscalendar and the recipient has to convert back to icalendar - what timezone do they use for the recurrenceid? Best guess is he wrong one "Europe/London". But how about this: BEGIN:VEVENT DTEND;TZID=America/New_York:20200828T100000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC G@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200828T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T222119Z DTSTART;TZID=America/New_York:20200828T090000 CREATED:20200823T221135Z ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com:mailto:mdouglass@ bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT BEGIN:VEVENT DTEND;TZID=Europe/London:20200827T130000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC G@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200827T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T221349Z DTSTART;TZID=Europe/London:20200827T120000 CREATED:20200823T221135Z ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;PARTSTAT=NEEDS-AC TION;RSVP=TRUE:mailto:mdouglass@bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT On 8/23/20 00:19, Michael Douglass wrote: > I find the explanations about recurrenceId a little confusing. > > To be or not to be... > > When is it valid to actually have a recurrenceId property and if it > exists what are the constraints? > > It looks like it should never appear anywhere for a full calendar > object with master and overrides. > > It MUST appear in a 'detached' instance which represents a single > override - for example being invited to a single instance. > > Or - we could say it MAY appear in the override but its value MUST be > the same as the key. > > On timezones in overrides > > I haven't found anything in 5545 that says the tzid MUST be the tzid > in the master dtstart. Is it valid to have a recurrenceid with a > different timezone? > > I would suggest it shouldn't be. > > As it relates to jscalendar: > > The override keys are the local date time as calculated based on the > master start using the master timezone. > > What happens if an override changes the timezone? We can't use the > recurrenceId value as that's the local time in the master timezone. > > In iCalendar it's easy (I think). The recurrenceId timezone is > distinct from the dtstart timezone so if I want one instyance of my > meeting in London instead of New York I can easily override it. An > example in jscalendar would help (me). > > --------------4FCCF847FBA5F57B3C63CB5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    This is an example of where I have difficulties:

    BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7
 A@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=Europe/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA
 T=NEEDS-ACTION:mailto:mdouglass@bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

    When that's converted to jscalendar we will have a recurrence id based on "America/New_York"- which won't appear anywhere - and a start time based on "Europe/London".

    That might work sort of - the recurrenceid in this case could be treated just as a key.

    But what if that gets sent out as jscalendar and the recipient has to convert back to icalendar - what timezone do they use for the recurrenceid? Best guess is he wrong one "Europe/London".

    But how about this:

    BEGIN:VEVENT
DTEND;TZID=America/New_York:20200828T100000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
 G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200828T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T222119Z
DTSTART;TZID=America/New_York:20200828T090000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com:mailto:mdouglass@
 bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT
BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
 G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=Europe/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;PARTSTAT=NEEDS-AC
 TION;RSVP=TRUE:mailto:mdouglass@bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT






    On 8/23/20 00:19, Michael Douglass wrote:
    I find the explanations about recurrenceId a little confusing.

    To be or not to be...

    When is it valid to actually have a recurrenceId property and if it exists what are the constraints?

    It looks like it should never appear anywhere for a full calendar object with master and overrides.

    It MUST appear in a 'detached' instance which represents a single override - for example being invited to a single instance.

    Or - we could say it MAY appear in the override but its value MUST be the same as the key.

    On timezones in overrides

    I haven't found anything in 5545 that says the tzid MUST be the tzid in the master dtstart. Is it valid to have a recurrenceid with a different timezone?

    I would suggest it shouldn't be.

    As it relates to jscalendar:

    The override keys are the local date time as calculated based on the master start using the master timezone.

    What happens if an override changes the timezone? We can't use the recurrenceId value as that's the local time in the master timezone.

    In iCalendar it's easy (I think). The recurrenceId timezone is distinct from the dtstart timezone so if I want one instyance of my meeting in London instead of New York I can easily override it. An example in jscalendar would help (me).


    --------------4FCCF847FBA5F57B3C63CB5B-- From nobody Sun Aug 23 17:04:49 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794B53A03FB for ; Sun, 23 Aug 2020 17:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=qJJ+Wej3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D89nU9eC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PHctIPYlrir for ; Sun, 23 Aug 2020 17:04:45 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE4D3A03F6 for ; Sun, 23 Aug 2020 17:04:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B1B1312E9 for ; Sun, 23 Aug 2020 20:04:44 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 23 Aug 2020 20:04:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=yiMWU+A a5O+Zd483z4tQqafxcef/XuEJsPJWbC0SCDY=; b=qJJ+Wej3YkQpbV7eSypc5q0 oItMKjnU6Sm2j2Bx+B+y6L6ax7YzjeWn6d2FDu5u6CtlBdV419ON3nS/gPIxflAY /FASAUzhKyZRtcYm8Iq+NGmzVsZVQ/bV6gr6/a7T7PcB5iMXFQZ/mNGQQLpALuUg lbATtfsZLJRMPavTSC2m3QIXqCpcFgWTsEAYpPHAvKZXhPxF1PQnI+q9mHMWWCyg WLc88KnRE+AthU4oxfBisCP9rYVcoyhvc2FNtFmbsAhJzCQhpFl5I+bjIr9kq1OJ dnRnfnhqmjWaSH/SsqThI1hA8y1au1rLH4XY7/B0H9uqVYAFeD1NIBRIpaqLRcA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=yiMWU+ Aa5O+Zd483z4tQqafxcef/XuEJsPJWbC0SCDY=; b=D89nU9eCUYnZKdozYkcQmX zZYHMRYCRCKYKGw8itiI13b4OMysPO4hGtcYwcbfWjcsancBeK5DdOFGGpGWnnxk KUqrYWMZpG/jSDNs3XVATDFPnRyHmSnPpzDCq136DNbCvZPK7aq7FFHpORtAi4B3 M5uyja+QQV+ZCODNm2PBiSvQ/3W30KoTeAEP/YrDoA77IQ5mpkBPIO+QiSzo+PsL AY6hnCzX4F9zA0d1qVjtmxKyK/iQNQV443kocJ1A7QkbwLTlGJMfSkm92uZnKzte tJOUEI0p3qI+DpQ74B59pWhllVrHmmLReNVPqD+ZV9H90bsRu1z52H3mLk5kOlBw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepleevjefgtdegff ejvedtudfgtdetffeuvdfftedtheefvdetheekffekledvteeinecuffhomhgrihhnpehi vghtfhdrohhrghdpsggvuggvfihorhhkrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghm rdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 078B018014A; Sun, 23 Aug 2020 20:04:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882 Mime-Version: 1.0 Message-Id: In-Reply-To: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> Date: Mon, 24 Aug 2020 10:04:14 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b8a36537bed34bebadebf37bb1d67ca7 Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 00:04:47 -0000 --b8a36537bed34bebadebf37bb1d67ca7 Content-Type: text/plain On Sun, 23 Aug 2020, at 14:19, Michael Douglass wrote: > When is it valid to actually have a recurrenceId property and if it > exists what are the constraints? > > It looks like it should never appear anywhere for a full calendar object > with master and overrides. Correct. > It MUST appear in a 'detached' instance which represents a single > override - for example being invited to a single instance. Correct. > Or - we could say it MAY appear in the override but its value MUST be > the same as the key. No, see section 4.3.3 ; it's in the list of keys that you can't override. > On timezones in overrides > > I haven't found anything in 5545 that says the tzid MUST be the tzid in > the master dtstart. Is it valid to have a recurrenceid with a different > timezone? The recurrence id doesn't have a time zone (or if you prefer to think of it this way: its time zone is always that of the master event). > The override keys are the local date time as calculated based on the > master start using the master timezone. Yes. > What happens if an override changes the timezone? We can't use the > recurrenceId value as that's the local time in the master timezone. I don't really understand the question. This would change the start time, but has no effect on the recurrence id. > This is an example of where I have difficulties: > BEGIN:VEVENT DTEND;TZID=Europe/London:20200827T130000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7 A@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200827T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T221349Z DTSTART;TZID=Europe/London:20200827T120000 CREATED:20200823T221135Z > ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA T=NEEDS-ACTION:mailto:mdouglass@bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT > > When that's converted to jscalendar we will have a recurrence id based on "America/New_York"- which won't appear anywhere - and a start time based on "Europe/London". Yes, America/New_York will not appear anywhere. if you don't have the master event, it's not relevant. The recurrence id is used to identify unique instances of recurring events. Because we need to be able to generate an id for recurrences created by a recurrence rule, we use the generated date-time as the id. But it is still just an id, not a date. You can override the date of an occurrence (including the time zone of the date), but you can't override its id. > But what if that gets sent out as jscalendar and the recipient has to convert back to icalendar - what timezone do they use for the recurrenceid? Best guess is he wrong one "Europe/London". Is there a situation where this is actually going to make a difference though? > But how about this: > BEGIN:VEVENT DTEND;TZID=America/New_York:20200828T100000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC G@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200828T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T222119Z DTSTART;TZID=America/New_York:20200828T090000 CREATED:20200823T221135Z > ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com:mailto:mdouglass@ bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT BEGIN:VEVENT DTEND;TZID=Europe/London:20200827T130000 ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC G@imip.me.com UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 DTSTAMP:20200823T221311Z SEQUENCE:1 RECURRENCE-ID;TZID=America/New_York:20200827T090000 SUMMARY:Test rid + tzid LAST-MODIFIED:20200823T221349Z DTSTART;TZID=Europe/London:20200827T120000 CREATED:20200823T221135Z > ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;PARTSTAT=NEEDS-AC TION;RSVP=TRUE:mailto:mdouglass@bedework.com ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ END:VEVENT How about it? You have two individual instances, one with recurrenceId 2020-08-28T09:00:00 and the other 2020-08-27T09:00:00. The former object has time zone America/New_York and the latter Europe/London. Neil. --b8a36537bed34bebadebf37bb1d67ca7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Sun, 23= Aug 2020, at 14:19, Michael Douglass wrote:
    When is it valid to actually have a rec= urrenceId property and if it 
    exists what are the con= straints?

    It looks like it should never app= ear anywhere for a full calendar object 
    with master = and overrides.

    Correct.

    It= MUST appear in a 'detached' instance which represents a single 
    override - for example being invited to a single instance.

    Correct.

    Or - we could say = it MAY appear in the override but its value MUST be 
    = the same as the key.

    No, see s= ection 4.3.3; it's in the list of keys that you can't = override.

    On timezones in overrides

    I h= aven't found anything in 5545 that says the tzid MUST be the tzid in&nbs= p;
    the master dtstart. Is it valid to have a recurrenceid = with a different 
    timezone?

    The recurrence id doesn't have a time zone (or if you p= refer to think of it this way: its time zone is always that of the maste= r event).

    The override keys are the local date time as calculated ba= sed on the 
    master start using the master timezone.

    Yes.

    What happens if an ove= rride changes the timezone? We can't use the 
    recurre= nceId value as that's the local time in the master timezone.

    I don't really understand the question. T= his would change the start time, but has no effect on the recurrence id.=

    This is an example of where I have difficulties:

    BEGIN=
:VEVENT
DTEND;TZID=3DEurope/London:20200827T130000
ORGANIZER;CN=3DMichael Douglass;=
EMAIL=3Dmikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY=
7
 =
A@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=3DAmerica/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=3DEurope/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;=
CUTYPE=3DINDIVIDUAL;EMAIL=3Dmdouglass@bedework.com;RSVP=3DTRUE;PARTSTA
 T=3DNEEDS-ACTION:mailto:mdouglass@bedework.com
ATTENDEE;CN=3DMichael Douglass;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DACCEPTED;R=
OLE=3DCHA
 IR;EMAIL=3D=
mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

    When that's converted to jscalendar we will have a recurren= ce id based on "America/New_York"- which won't appear anywhere - and a start time based on "Europe/London".


    =
    Yes, America/New_York will not appear anywhere. if you don't = have the master event, it's not relevant. The recurrence id is used to i= dentify unique instances of recurring events. Because we need to be able= to generate an id for recurrences created by a recurrence rule, we use = the generated date-time as the id. But it is still just an id, not a dat= e. You can override the date of an occurrence (including the time zone o= f the date), but you can't override its id.

    But what if that gets sent= out as jscalendar and the recipient has to convert back to icalendar - what timezone do they use for the recurrenceid? Best guess is he wrong one "Europe/London".
    <= /p>


    Is there a situation where this is a= ctually going to make a difference though?

    But how about th= is:

    BEGIN:VEVENT
DTEND;TZID=3DAmerica/New_York:20200828T100000
ORGANIZER;CN=3DMichael Douglass;=
EMAIL=3Dmikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJ=
C
 =
G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=3DAmerica/New_York:20200828T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T222119Z
DTSTART;TZID=3DAmerica/New_York:20200828T090000
CREATED:20200823T221135Z
ATTENDEE;CU=
TYPE=3DINDIVIDUAL;EMAIL=3Dmdouglass@bedework.com:mailto:mdouglass@
 bedework.com
ATTENDEE;CN=3DMichael Douglass;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DACCEPTED;R=
OLE=3DCHA
 IR;EMAIL=3D=
mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT
BEGIN:VEVENT
DTEND;TZID=3DEurope/London:20200827T130000
ORGANIZER;CN=3DMichael Douglass;=
EMAIL=3Dmikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJ=
C
 =
G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=3DAmerica/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=3DEurope/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;=
CUTYPE=3DINDIVIDUAL;EMAIL=3Dmdouglass@bedework.com;PARTSTAT=3DNEEDS-AC
 TION;RSVP=3DTRUE:mailto:mdouglass@bedework.com
ATTENDEE;CN=3DMichael Douglass;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DACCEPTED;R=
OLE=3DCHA
 IR;EMAIL=3D=
mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

    How about it?= You have two individual instances, one with recurrenceId 2020-08-28T09:= 00:00 and the other 2020-08-27T09:00:00. The former object has time zone= America/New_York and the latter Europe/London.

    =
    Neil.
    --b8a36537bed34bebadebf37bb1d67ca7-- From nobody Sun Aug 23 17:55:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8CC3A0848 for ; Sun, 23 Aug 2020 17:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn56HDxzN--m for ; Sun, 23 Aug 2020 17:55:17 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799A33A0846 for ; Sun, 23 Aug 2020 17:55:17 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id u3so6086215qkd.9 for ; Sun, 23 Aug 2020 17:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=J8ON9t2jEXncB5zkd8lSvofibcHi/XHPGlQGRaLXYJY=; b=WW/flyd2ce4LIMazSTKiDoG2rMexaZZii5p7JmNUHJ4v/oYChza0fhzmx5J5Gt2TRj R4F3rHhZAEMq66yPiFrNl/PU/4ppLVU4sj4YNO/1kvQhYi5dYk8fU2bwgLw2F/5v9dpj M1VNZy+X87qe5U9MmJpwnZ+s6EeqHhR3UjnKE3Wm+WMtJ/bPwZmZ8G25ij8YonuPYE+U aIICYJwqXNG2Sd3lmHdMmXmfh3X9bujtLdcbef3cDDs0DXJ1/EIOS4fsVL/L9KZNyZUd 2edfL6x9Wc4oFWA2NlIt/4Uf+Q3PokKcyMRMFmAVpyqs3VCSVU6Dol5+JX58OSqV/fug PFdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=J8ON9t2jEXncB5zkd8lSvofibcHi/XHPGlQGRaLXYJY=; b=BQqn+hHlUA7ulCkVKy6adJXuPXhOGWTaGmT2t5BOfLm9RWSUtdDrj4bTwOWf4/LW81 fCnIGxJ3rs/YVtXEjl3/OhFmAJH1VBzBvSlO/GkJEfabMBIpE7Upq4dyiDHd1ZRuV5Px ftg9Yl/nN8bWz637jk44ZuGuKH1y1lWaKTUgXeoazB6ql8l6+ov2McRb3orJwTjDTgqW O6Urs3vaFomGhW921i5ETLECALk7W/pi+9droaIdO8DhWQRPEixup6i5lgGRyjua30V8 HplnMgnR74y1WtFQfLDn0viDLJA6K3LAoKLKT7SX/pQrt/tkjATxiSiiLelBkBHid2TD QILA== X-Gm-Message-State: AOAM532u6fCWBzc/rCLBVWCWhrSNt3Ku0Ftu61+bgRqNrFJSiJFf2JCs KXRy26ef49Gcc3buRzDkPBZo2LhEq8bU+g== X-Google-Smtp-Source: ABdhPJztw2yIzmm9N+ioLY5m5+8t6XX81+4t5/XtDkBSIHbCkaUPp5z+QbuMl+FlDPy/0TIx+C+UVQ== X-Received: by 2002:a37:9ccd:: with SMTP id f196mr768965qke.55.1598230516142; Sun, 23 Aug 2020 17:55:16 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id c205sm8446910qkg.98.2020.08.23.17.55.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 17:55:15 -0700 (PDT) To: calsify@ietf.org References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> From: Michael Douglass Message-ID: <4b3d9de7-ad1e-c6b4-ab80-2c74af9c10fd@gmail.com> Date: Sun, 23 Aug 2020 20:55:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2FC1A913DB7D803C5095FEEB" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 00:55:19 -0000 This is a multi-part message in MIME format. --------------2FC1A913DB7D803C5095FEEB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/23/20 20:04, Neil Jenkins wrote: >> >> But how about this: >> >> BEGIN:VEVENT >> DTEND;TZID=America/New_York:20200828T100000 >> ORGANIZER;CN=MichaelDouglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T >> GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC >> G@imip.me.com >> UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 >> DTSTAMP:20200823T221311Z >> SEQUENCE:1 >> RECURRENCE-ID;TZID=America/New_York:20200828T090000 >> SUMMARY:Test rid + tzid >> LAST-MODIFIED:20200823T222119Z >> DTSTART;TZID=America/New_York:20200828T090000 >> CREATED:20200823T221135Z >> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com:mailto:mdouglass@ >> bedework.com >> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA >> IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh >> cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ >> END:VEVENT >> BEGIN:VEVENT >> DTEND;TZID=Europe/London:20200827T130000 >> ORGANIZER;CN=MichaelDouglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T >> GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC >> G@imip.me.com >> UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 >> DTSTAMP:20200823T221311Z >> SEQUENCE:1 >> RECURRENCE-ID;TZID=America/New_York:20200827T090000 >> SUMMARY:Test rid + tzid >> LAST-MODIFIED:20200823T221349Z >> DTSTART;TZID=Europe/London:20200827T120000 >> CREATED:20200823T221135Z >> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;PARTSTAT=NEEDS-AC >> TION;RSVP=TRUE:mailto:mdouglass@bedework.com >> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA >> IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh >> cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ >> END:VEVENT > > How about it? You have two individual instances, one with recurrenceId > 2020-08-28T09:00:00 and the other 2020-08-27T09:00:00. The former > object has time zone America/New_York and the latter Europe/London. If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar. What's going to come back to the organizer as a reply? Probably something with incorrect recurrenceids > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------2FC1A913DB7D803C5095FEEB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


    On 8/23/20 20:04, Neil Jenkins wrote:

    But how about this:

    BEGIN:VEVENT
DTEND;TZID=America/New_York:20200828T100000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
 G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200828T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T222119Z
DTSTART;TZID=America/New_York:20200828T090000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com:mailto:mdouglass@
 bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT
BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
 G@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=Europe/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;PARTSTAT=NEEDS-AC
 TION;RSVP=TRUE:mailto:mdouglass@bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

    How about it? You have two individual instances, one with recurrenceId 2020-08-28T09:00:00 and the other 2020-08-27T09:00:00. The former object has time zone America/New_York and the latter Europe/London.

    If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar.

    What's going to come back to the organizer as a reply? Probably something with incorrect recurrenceids



    Neil.

    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------2FC1A913DB7D803C5095FEEB-- From nobody Sun Aug 23 17:56:34 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3BF3A0849 for ; Sun, 23 Aug 2020 17:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JgoqxY7Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aNEQi0ZM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t972--xxsIvd for ; Sun, 23 Aug 2020 17:56:32 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB863A0848 for ; Sun, 23 Aug 2020 17:56:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 12A225DA for ; Sun, 23 Aug 2020 20:56:31 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sun, 23 Aug 2020 20:56:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=WB8vh5c MttWdSIT65KQ8USa6REc6aWEQc5QjSAb9uvA=; b=JgoqxY7Z7vSqrHE/w1BpK7O wjuSe8HiIf6h3lTiR+gkdf3Epd8UUk25OABKb8+LsCriT0KCZoFepkhj1O8BUqrq Eg/2xL6XedtVMeqll1+tzL7OLZ7t4b89tCnHlXD+yL15BTnWxaeBbBpIM7kXvfhh 4/btF3shLjnZHf1005H8uv1MgdlLiwi8k7fsgtcuYM7dXrysIDeEiuODC2sRyoC/ AYObOX3Xnyx12dwOcO0QJ7N8Irx4YFq+rDnQfdx5ntxINyF9f9O5USClMoYsnYdW Oy0YvBu6ewlsbD1yOjfhLs/Flz07/mqhmy0i496Eh0KmbnJVNo3X/TnO6sZ2+ow= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=WB8vh5 cMttWdSIT65KQ8USa6REc6aWEQc5QjSAb9uvA=; b=aNEQi0ZM0z77hwdqA1puQo 0wCMSWqJCygQ6QQmtUEn19nn1Zve+iRjxyhw5RoqICnKqjIiOBQZ4XHJcOVzSWjs pYJT2vfJDKPlu+QOQyZ1qcrHbuNdAaGQwvA2Xm/XDVSuwYBTuS+anrUss1FFfPR+ UyCkMwW/fn5uEUn3sn5Wtdkm0u6p6D2BqWJGObESbRdG9qsEFJ4X8Xg0pT+8leX8 czG/pGgZKtqT9fgweuHlBfpraKkxfeUAO3x6PGHmpdXpiEEvoO7wixFOKmxjXiqX 3QcJmgsMdnBXQTBLIJM+z5lgni5viL/shyg7JTfolwVMP5CAcADxfrifhgYAE7Uw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9018018014A; Sun, 23 Aug 2020 20:56:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882 Mime-Version: 1.0 Message-Id: In-Reply-To: <4b3d9de7-ad1e-c6b4-ab80-2c74af9c10fd@gmail.com> References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> <4b3d9de7-ad1e-c6b4-ab80-2c74af9c10fd@gmail.com> Date: Mon, 24 Aug 2020 10:56:30 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=12961b1409474a5fa2aa74e0f3d7f72f Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 00:56:33 -0000 --12961b1409474a5fa2aa74e0f3d7f72f Content-Type: text/plain On Mon, 24 Aug 2020, at 10:55, Michael Douglass wrote: > If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar. > What's going to come back to the organizer as a reply? If you were sent JSCalendar, presumably the sender will accept JSCalendar in return so it doesn't matter. Neil. --12961b1409474a5fa2aa74e0f3d7f72f Content-Type: text/html
    On Mon, 24 Aug 2020, at 10:55, Michael Douglass wrote:
    If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar.
    What's going to come back to the organizer as a reply?

    If you were sent JSCalendar, presumably the sender will accept JSCalendar in return so it doesn't matter.

    Neil.
    --12961b1409474a5fa2aa74e0f3d7f72f-- From nobody Sun Aug 23 21:07:18 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200CA3A09AB for ; Sun, 23 Aug 2020 21:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmgE1WQbl9wL for ; Sun, 23 Aug 2020 21:07:15 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1C93A09AA for ; Sun, 23 Aug 2020 21:07:15 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id x69so6337594qkb.1 for ; Sun, 23 Aug 2020 21:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Oojjyjfi8Aj3EHdw+Bny5HCk4Lo/caoYaoM6cHbxlD0=; b=dCaq91kG17dJqAgemiX8AnCAWDVQ5L+ZZDtMI/sqtK6NJ8g4Xrcy1eHpYoTBiSvKFH iBNJfg5Im/A+USV6Uc1yLBweP/uBv5rj+qAQR0daXkqLdrMZCGrFi+DhbjQhpjqYBAg5 w0QEIp8ZhtJndnZZgKiLyKRhfkxxwVZ9lnk8oxls7sLpQtFxjppRCNKZjOikx3OlgHxb 1d5h8xYwOY2jOj/p96xaRjWpEG7jyFoV0ehJyI5UpLEMh6ysx1RuFe+v1q2ODFTuVqNV JZ47AAGIOQgjOYHrzCu9cUHENTjcjZBiMXGtwAhf9mWY18q0yzLEhTrukMoMPcppQEWn oQ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Oojjyjfi8Aj3EHdw+Bny5HCk4Lo/caoYaoM6cHbxlD0=; b=KfTNKiXsrURLyvrAhgUyPEjnDFoMOSjKzSkarW99JozOwBVehLe0E8MoHKow+c2s0x ct2/sdMWJCGhsiPpWINIAS8omijhrpIX+Ij6y9ITEfCY3kdQAvnqB8DIOeM+cbby8ROx VHPnmFURzvd3NE3YURU4WVs8xbUmatP273sFMkzCT8gh0ijZrShSB88Jl0skgb22pMSY TTLiFAVQuvcbVdgXPbJgeprqlbQR8omJi2oFoDx4Xd2T+y+w3Xgot6iE43rsr+0yvBiK yrTwDCiAud6PRJbNKuh78iZJRv/Zw2qWfdUcYk1LGO80bZxlKHnxPOO13BHDxwYaC9lt JDSw== X-Gm-Message-State: AOAM532jc2qsHViR4mf12xxFQjr00lfqL/zSI+l4yV5pv2nn5fisE86V 608MamZBoGxH6Hu/oxGVpE/bsrynw7GINg== X-Google-Smtp-Source: ABdhPJzZd9Xl6ZUU7+PW4osx+OVPz5YW7ljWJ1MwlGd3C+AgczIA54oadUoDzB64eSQZ2zFYCRzdCw== X-Received: by 2002:a05:620a:1525:: with SMTP id n5mr3149672qkk.126.1598242034634; Sun, 23 Aug 2020 21:07:14 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id l13sm9652476qth.77.2020.08.23.21.07.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 21:07:14 -0700 (PDT) To: calsify@ietf.org References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> <4b3d9de7-ad1e-c6b4-ab80-2c74af9c10fd@gmail.com> From: Michael Douglass Message-ID: Date: Mon, 24 Aug 2020 00:07:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9CA95A36D90D6DCDBA48C44E" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 04:07:17 -0000 This is a multi-part message in MIME format. --------------9CA95A36D90D6DCDBA48C44E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/23/20 20:56, Neil Jenkins wrote: > On Mon, 24 Aug 2020, at 10:55, Michael Douglass wrote: >> If I'm sent the jscalendar version I can't construct a valid/correct >> representation of it as iCalendar. >> What's going to come back to the organizer as a reply? > > If you were sent JSCalendar, presumably the sender will accept > JSCalendar in return so it doesn't matter. Only if the recipient knows to respond in jscalendar. It may not. I think essentially your saying that iTip won't work correctly in certain cases if we mix iCalendar and jscalendar? > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------9CA95A36D90D6DCDBA48C44E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


    On 8/23/20 20:56, Neil Jenkins wrote:
    On Mon, 24 Aug 2020, at 10:55, Michael Douglass wrote:
    If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar.
    What's going to come back to the organizer as a reply?

    If you were sent JSCalendar, presumably the sender will accept JSCalendar in return so it doesn't matter.

    Only if the recipient knows to respond in jscalendar. It may not.

    I think essentially your saying that iTip won't work correctly in certain cases if we mix iCalendar and jscalendar?


    Neil.

    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------9CA95A36D90D6DCDBA48C44E-- From nobody Sun Aug 23 22:19:35 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E503A0A34 for ; Sun, 23 Aug 2020 22:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu1ciIMdTpWc for ; Sun, 23 Aug 2020 22:19:33 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966A23A0A2D for ; Sun, 23 Aug 2020 22:19:33 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id cs12so3242729qvb.2 for ; Sun, 23 Aug 2020 22:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=yDLP8JPKBPOlNrKuh2Gq+zjqDlAoN3EM6WcKgdzpjts=; b=Ksh8QBfmSlu8+1J6UqUU9nYMhkVtoVNg/H4ab1f7MbAgYFzet0gP9hCM21JC7H2T6K NYed5GZoUqoibT7CIfGFmYiicAFpChJpVAAWw/qmiTlvLn5huAKudBWmPYKdMoQg6uMx 3urylhoRO5GxUIq+Y4B6RsQfqqwINGQSYIZFag9daaAvOnD+OrBwSNtkpC6nUe5Z1QUY zn+1nx1Mhp2/dUEZi3D4JI4AmpjrP1ayy0sq6QHsP5fHD9Bg1aV/p83dCNCUGBmHVazM czrsxWJqxkFHIctQfO3Y0n+UbUfo9WONRAcD2MywatJx476CJ4Zhvr8mDwawMbr6NZRf 2kQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=yDLP8JPKBPOlNrKuh2Gq+zjqDlAoN3EM6WcKgdzpjts=; b=MNBEn/TzFJzYsoC7vfHfbWMInie8u8uvtu5mAJXVJw9kkjBG03kcI6DJlai7i2jfYJ gTh1I0GtePTZvUjup2qpJ0UNcsWZy1N8plA3xP3f74syNGJ3cZX97kTLgphSqStCvADc Eh2pQQP+prk7k7Jr4cE0x4OL55aa/syyxRr3lLpVrmY1tR6FjCTKibxV9P7of0vUh8aF EBS7OUZLSfYDnELF+MQA4enLQ2c4+z8Na9q4au2UeO9koUfGz7P9uGd92CczN+NXglSk 7FcK6L6lBNh6pU/vTiLYdv5rxHjkorjOfm/jQlfzI0tIHFXqS9ZoV3kxEBH6G51Xf6Dw 9OIw== X-Gm-Message-State: AOAM532zikbejG7ckI4irKIaL91Ti/X7ag15bX3jVWwz41fmy59I98hj t/FKssWGkhD/keGU/h3LpCw2ZQEG9oZImQ== X-Google-Smtp-Source: ABdhPJxWDbFyLWfV8sj8CHPS4OIukKP2Br3VHXAN0VJM3yJmp3l7cWsNeRknSW4W60tzqHNN8jHBfQ== X-Received: by 2002:a0c:ca86:: with SMTP id a6mr3402023qvk.209.1598246372485; Sun, 23 Aug 2020 22:19:32 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id y194sm755602qkb.116.2020.08.23.22.19.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 22:19:31 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <8f9e0714-befa-604b-4e33-479b3be1c7e0@gmail.com> Date: Mon, 24 Aug 2020 01:19:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] JSCalendar - showWithoutTime X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 05:19:34 -0000 Shouldn't that be on the list of forbidden patches in section 4.3.4? From nobody Sun Aug 23 22:57:15 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A2D3A0A4E for ; Sun, 23 Aug 2020 22:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=G8OaSikL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dxk/YIiq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahiq_ReY58CL for ; Sun, 23 Aug 2020 22:57:12 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982EA3A0A4D for ; Sun, 23 Aug 2020 22:57:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id C5DCB2C4 for ; Mon, 24 Aug 2020 01:57:11 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 24 Aug 2020 01:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=kwZT3KP piborrT0+mUd3340uLypIGf/0DkXLJpf8oY4=; b=G8OaSikLIYrN2Q6HwCLV9HM daqSPLe3WbxGy9iMmfo2Ho/6gIbFF5bC2TJ8IxHgQ8gWiLqoLNmCLEaCIND5i5EE jorJPJRifXacY46sZ0D62sThNU+RzO0Irc3ToBHvujpPzsmINKus3lx3fmVO9V6j uTPngJIIeNngfZsAmmVFtZkSklt9qbf2HynZdgw1YCD+kxsmUL98Y9kRjq5JGiwO ZiE5RsJqPzE+Lazmc/7hoFNEqmbLneKTYMc4/gv7qK7H2XJA/XsqHbXT6UPIUhFp pGYBB4cINIzqtJcjGLcTK79zq4Heo6WChU8yiO1a/WBYxslmBOWkWZhEPNFLwBQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=kwZT3K PpiborrT0+mUd3340uLypIGf/0DkXLJpf8oY4=; b=Dxk/YIiq/bQbGID0NS8Hn6 pfPAoSi58QAt0rkTVt1yZApH8uQ3eIBIH7l4mdESFtkmyo3Xcl8VnPVwc2QWrL5Y /dMNtKEtdZ6msiEVK+O4f2x2PU6bgesRCFWhYtRvKOAkixrtiT0nmX8xYOtUDS/W RoRnw0XJCD2Lohzc9D13ETNO25C83sgPBOKZWOb4ZM+bc8bi28+XSaRR2WQnTUZW UexN/SN9Sw2Ul0jS9tX+hQKj7Zp7yjEjHJUY80N/jiSEjHvligWvfLAmhkaIx+Bn E3VaHShNk0TESDXaZrhXr/gQpd3VlNHsAwNN9ZQIHPo0bHuVff8GHux5L8rj9R+Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfelheffteefue eivdekgeeijeeiuefhudfgveellefgveduteeutdelieeggfejnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3931B18014A; Mon, 24 Aug 2020 01:57:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882 Mime-Version: 1.0 Message-Id: <40b92261-3747-4286-9b6b-ac6612d8dc78@dogfood.fastmail.com> In-Reply-To: <8f9e0714-befa-604b-4e33-479b3be1c7e0@gmail.com> References: <8f9e0714-befa-604b-4e33-479b3be1c7e0@gmail.com> Date: Mon, 24 Aug 2020 15:57:10 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=19468681d0324b6a9386e4be06823397 Archived-At: Subject: Re: [calsify] JSCalendar - showWithoutTime X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 05:57:14 -0000 --19468681d0324b6a9386e4be06823397 Content-Type: text/plain On Mon, 24 Aug 2020, at 15:19, Michael Douglass wrote: > Shouldn't that be on the list of forbidden patches in section 4.3.4? It used to be, but was removed from the list following this discussion on the calsify list in June last year. I believe the idea is that since this is really just signifying a UI preference (to display without time), there is no reason you can't override it for individual occurrences. Neil. --19468681d0324b6a9386e4be06823397 Content-Type: text/html
    On Mon, 24 Aug 2020, at 15:19, Michael Douglass wrote:
    Shouldn't that be on the list of forbidden patches in section 4.3.4?

    It used to be, but was removed from the list following this discussion on the calsify list in June last year. I believe the idea is that since this is really just signifying a UI preference (to display without time), there is no reason you can't override it for individual occurrences.

    Neil.
    --19468681d0324b6a9386e4be06823397-- From nobody Sun Aug 23 23:05:52 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486573A0A69 for ; Sun, 23 Aug 2020 23:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rCXm2W5e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LWD75RtF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdkLGRRvYYII for ; Sun, 23 Aug 2020 23:05:50 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9473A0A64 for ; Sun, 23 Aug 2020 23:05:50 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7FA5D6F3 for ; Mon, 24 Aug 2020 02:05:49 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 24 Aug 2020 02:05:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=eFbE5yQ 8U6Ur39s8+c51ZU54IINJ6tLs1bmcZ8ylXdc=; b=rCXm2W5e9M1AittEEnlePor 823T2Bn1arHBimPSK0cAZTF+MFKJicbRIcLTICFPSn+eGh27OK/myRnPdBIjy+B1 5zVvcGVb57ZC2OhYzSx1a6eUfvfmhdCAlDK9Q7lvyionluAYPrek6kdApyxvq8gw QezGJZrrYEOOotDk57mHnEBEAN09z3O8nsNMaVfK5Y8S1RbkJU2QMSxwazQqrvBd BADd74twiLsmASujH2UAfM7RM7u5AawimFvawMW9Wwp7JlkkbbToC/t5mElMMcSL F4JGWpVsPlfzYfz5KZSOMqJ1e2jWONcINdEZUgw7KPmbf90/S8H4Ie4EiAMC0Pg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eFbE5y Q8U6Ur39s8+c51ZU54IINJ6tLs1bmcZ8ylXdc=; b=LWD75RtFy2D9d9hZ8AO0WC /thAa3UC3xAZpc3NOnnlnRTvXlk75WGbTn2Op/KdmR5XuONK0/drWj48L+0IS6oA nqXVfTI6pNG1zrqLW8g+AoygH8fZ8Mfwu2qhxOJ7gpc6n/TKKWsv/jwNpB5MwE9r 8zK1LmR8E2rcO/EMZJUpU8W05UQ10OfB5Enen+nxO2LBn/q2YIUYj3v9Pkvnf4b7 m1HjTp5ZYhdtuynIRiL7xrUpSdsETwj7G+lHc3jNDZIiJmlRpX6S9XAigR3keQ/C s5k9xv6B7l0MQQ/LZ1HZUnlV/b0MOEYSgNpxV/P3/XwwG+MMdMjyfl8jkJp/UipA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D219B18014A; Mon, 24 Aug 2020 02:05:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882 Mime-Version: 1.0 Message-Id: <20a51e6a-9e10-4d65-97d5-f11bad4696f1@dogfood.fastmail.com> In-Reply-To: References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> <4b3d9de7-ad1e-c6b4-ab80-2c74af9c10fd@gmail.com> Date: Mon, 24 Aug 2020 16:05:48 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f1078119c2654ddda524261722332d92 Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 06:05:51 -0000 --f1078119c2654ddda524261722332d92 Content-Type: text/plain On Mon, 24 Aug 2020, at 14:07, Michael Douglass wrote: > Only if the recipient knows to respond in jscalendar. It may not. If the recipient doesn't understand JSCalendar they will respond to the iCalendar version (which you will have to include for iMIP for sometime at least, as you have no idea what the recipient's server supports). If they do understand JSCalendar and respond to the JSCalendar then the situation is irrelevant. So the issue would be only if you receive it as JSCalendar but respond with iCalendar, and I can't really see why you would do that? Neil. --f1078119c2654ddda524261722332d92 Content-Type: text/html
    On Mon, 24 Aug 2020, at 14:07, Michael Douglass wrote:
    Only if the recipient knows to respond in jscalendar. It may not.

    If the recipient doesn't understand JSCalendar they will respond to the iCalendar version (which you will have to include for iMIP for sometime at least, as you have no idea what the recipient's server supports). If they do understand JSCalendar and respond to the JSCalendar then the situation is irrelevant. So the issue would be only if you receive it as JSCalendar but respond with iCalendar, and I can't really see why you would do that?

    Neil.
    --f1078119c2654ddda524261722332d92-- From nobody Wed Aug 26 12:20:27 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5433A0893 for ; Wed, 26 Aug 2020 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=b3/doBwX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sp9GiTwi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbJjcc1gxncc for ; Wed, 26 Aug 2020 12:20:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D281A3A086D for ; Wed, 26 Aug 2020 12:20:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E78185C0130 for ; Wed, 26 Aug 2020 15:20:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 15:20:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=BSP+WE9K8XXv6CDZJ86FoYikPfr kn1uAy0GT+JmCNlQ=; b=b3/doBwX11jJ/Dx74irNax9luYuMus1ooFuoGUAK72t qxH91KgvQFdkAidWd5BVN+7wYZUdyr+f6/UVe3rbD8KTPtMggehS+sqyoKjCJ5pF vB39OZKZllfs5eru7L+DULxXWuCpAGv+qQWcyAm7tTuA2FrIApCbKUiqPuGXEZLP GJEeGfze4ly/cC4kbCVrusxCL0UGxT+U428iDR6SaNkCWAuCIdaU4/+A2geFImg+ 4qztqqevGMT31GDxllkia2zaFfhsQGpOJeKzQ8eMPX+HoFTU2e+kxvdeU5GS/xxt 45KPkg8QHPblBA3AAKZZWmOacB9fPAWfBy4MlP+aQzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=BSP+WE 9K8XXv6CDZJ86FoYikPfrkn1uAy0GT+JmCNlQ=; b=sp9GiTwikzhLmla0BSRTwr uoPijqRPKA1DjmHqbhqLxi6SRj+4LKS+GMKLncXJJgvHTAMF3MKOydbCjaR7yGaI maZapIEvxXdQslZlOCyxgLhQX0wj8//kciCeAUeXWcTJpRrQQQLo7K1Lxp9QqJw4 zEU3sr5Qt8GfbvcbqKZ24ytsp4O1X6/Iirn4Cls7UjIQnNkDgsLvzrHZ/ZWYvo85 vTBeCi2IRf+VDvfwz0GunqmGMkA5lRkxO8eT+hRcm1kE5kMk26kuz7iFMbOuCjZg +vTNVlQdY4l1DauaPOYp1LQms0HXbmDC4hY4/iOqvRXmDfbkm0eEPqbJWezW6zHg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvvddgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeffuefhvefggfdvudeuvdetie ejuedvvdekudeggedvffevgfduffeuieelgeeggeenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 084E130600B4 for ; Wed, 26 Aug 2020 15:20:22 -0400 (EDT) To: calsify@ietf.org References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> From: Ken Murchison Message-ID: Date: Wed, 26 Aug 2020 15:20:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E825141A5B05B53F6D2D5FB9" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 19:20:26 -0000 This is a multi-part message in MIME format. --------------E825141A5B05B53F6D2D5FB9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/23/20 8:04 PM, Neil Jenkins wrote: > On Sun, 23 Aug 2020, at 14:19, Michael Douglass wrote: >> When is it valid to actually have a recurrenceId property and if it >> exists what are the constraints? >> >> It looks like it should never appear anywhere for a full calendar object >> with master and overrides. > > Correct. > >> It MUST appear in a 'detached' instance which represents a single >> override - for example being invited to a single instance. > > Correct. > >> Or - we could say it MAY appear in the override but its value MUST be >> the same as the key. > > No, see section 4.3.3 > ; > it's in the list of keys that you can't override. > >> On timezones in overrides >> >> I haven't found anything in 5545 that says the tzid MUST be the tzid in >> the master dtstart. Is it valid to have a recurrenceid with a different >> timezone? > > The recurrence id doesn't have a time zone (or if you prefer to think > of it this way: its time zone is always that of the master event). > >> The override keys are the local date time as calculated based on the >> master start using the master timezone. > > Yes. > >> What happens if an override changes the timezone? We can't use the >> recurrenceId value as that's the local time in the master timezone. > > I don't really understand the question. This would change the start > time, but has no effect on the recurrence id. > >> This is an example of where I have difficulties: >> >> BEGIN:VEVENT >> DTEND;TZID=Europe/London:20200827T130000 >> ORGANIZER;CN=MichaelDouglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T >> GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7 >> A@imip.me.com >> UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622 >> DTSTAMP:20200823T221311Z >> SEQUENCE:1 >> RECURRENCE-ID;TZID=America/New_York:20200827T090000 >> SUMMARY:Test rid + tzid >> LAST-MODIFIED:20200823T221349Z >> DTSTART;TZID=Europe/London:20200827T120000 >> CREATED:20200823T221135Z >> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA >> T=NEEDS-ACTION:mailto:mdouglass@bedework.com >> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA >> IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh >> cljjCSqMYrUXDcs6f1z7CyXejTR/principal/ >> END:VEVENT >> >> When that's converted to jscalendar we will have a recurrence id >> based on "America/New_York"- which won't appear anywhere - and a >> start time based on "Europe/London". >> > > Yes, America/New_York will not appear anywhere. if you don't have the > master event, it's not relevant. The recurrence id is used to identify > unique instances of recurring events. Because we need to be able to > generate an id for recurrences created by a recurrence rule, we use > the generated date-time as the id. But it is still just an id, not a > date. You can override the date of an occurrence (including the time > zone of the date), but you can't override its id. > >> But what if that gets sent out as jscalendar and the recipient has to >> convert back to icalendar - what timezone do they use for the >> recurrenceid? Best guess is he wrong one "Europe/London". >> > > Is there a situation where this is actually going to make a difference > though? Maybe, but I don't think we have done enough testing to know for sure either way.  I think it would be wise for us to do some interop testing among different vendors (we now have at least 2), especially when it comes to scheduling and iTIP.  The Apple CalDAVTester has a healthy set of tests, including edge-cases such as above, and would be a good base to start from. The Fastmail/Cyrus server stores calendar resources internally as iCalendar so it routinely converts JSCalendar -> iCalendar -> JSCalendar.  I think that we have said that not all JSCalendar resources can be represented as iCalendar, but if the reverse ends up being true, I think we are making a mistake if we publish without addressing any such shortcomings as it would likely hinder adoption. -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------E825141A5B05B53F6D2D5FB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    On 8/23/20 8:04 PM, Neil Jenkins wrote:
    On Sun, 23 Aug 2020, at 14:19, Michael Douglass wrote:
    When is it valid to actually have a recurrenceId property and if it 
    exists what are the constraints?

    It looks like it should never appear anywhere for a full calendar object 
    with master and overrides.

    Correct.

    It MUST appear in a 'detached' instance which represents a single 
    override - for example being invited to a single instance.

    Correct.

    Or - we could say it MAY appear in the override but its value MUST be 
    the same as the key.

    No, see section 4.3.3; it's in the list of keys that you can't override.

    On timezones in overrides

    I haven't found anything in 5545 that says the tzid MUST be the tzid in 
    the master dtstart. Is it valid to have a recurrenceid with a different 
    timezone?

    The recurrence id doesn't have a time zone (or if you prefer to think of it this way: its time zone is always that of the master event).

    The override keys are the local date time as calculated based on the 
    master start using the master timezone.

    Yes.

    What happens if an override changes the timezone? We can't use the 
    recurrenceId value as that's the local time in the master timezone.

    I don't really understand the question. This would change the start time, but has no effect on the recurrence id.

    This is an example of where I have difficulties:

    BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=mikeadouglass@gmail.com:mailto:2_GM4T
 GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7
 A@imip.me.com
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200827T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T221349Z
DTSTART;TZID=Europe/London:20200827T120000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=mdouglass@bedework.com;RSVP=TRUE;PARTSTA
 T=NEEDS-ACTION:mailto:mdouglass@bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
 IR;EMAIL=mikeadouglass@gmail.com:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
 cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

    When that's converted to jscalendar we will have a recurrence id based on "America/New_York"- which won't appear anywhere - and a start time based on "Europe/London".


    Yes, America/New_York will not appear anywhere. if you don't have the master event, it's not relevant. The recurrence id is used to identify unique instances of recurring events. Because we need to be able to generate an id for recurrences created by a recurrence rule, we use the generated date-time as the id. But it is still just an id, not a date. You can override the date of an occurrence (including the time zone of the date), but you can't override its id.

    But what if that gets sent out as jscalendar and the recipient has to convert back to icalendar - what timezone do they use for the recurrenceid? Best guess is he wrong one "Europe/London".


    Is there a situation where this is actually going to make a difference though?


    Maybe, but I don't think we have done enough testing to know for sure either way.  I think it would be wise for us to do some interop testing among different vendors (we now have at least 2), especially when it comes to scheduling and iTIP.  The Apple CalDAVTester has a healthy set of tests, including edge-cases such as above, and would be a good base to start from.

    The Fastmail/Cyrus server stores calendar resources internally as iCalendar so it routinely converts JSCalendar -> iCalendar -> JSCalendar.  I think that we have said that not all JSCalendar resources can be represented as iCalendar, but if the reverse ends up being true, I think we are making a mistake if we publish without addressing any such shortcomings as it would likely hinder adoption.


    -- 
    Kenneth Murchison
Senior Software Developer
Fastmail US LLC
    --------------E825141A5B05B53F6D2D5FB9-- From nobody Wed Aug 26 18:11:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD03A0C20 for ; Wed, 26 Aug 2020 18:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ah1eWfnI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t18vpnXW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMWrHsWlLIIQ for ; Wed, 26 Aug 2020 18:11:14 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A143A0BF7 for ; Wed, 26 Aug 2020 18:11:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 940805C01E8 for ; Wed, 26 Aug 2020 21:11:13 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 21:11:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=2sHIveY XhqnqIGDNQl6KG/qC0qGlmXXyNsi5d2K21Ts=; b=Ah1eWfnI7h+po/623fFSQYz im4RYUtOPqgNBfnUg429Kdtt5m50RdBoOniWbPBBuAUUiCkXOyeUyJhHH6uKyOvC YXo+FlqCN/zMkCm2gj1gyeK5DhfwOJN3oauIrD+lUzJYuzlqsA5r6zpdi3Kc9pkr +QmUEG/B3+53C3zcd8C035sfOk1n2I5t9mEqEZVRvJGU/n7yOx74rY2jf0wTASyY zFT/CsIasFKvAzqu8GwnZN8jFQ0Is/pwX7TUe5rYe6V7S0zhOgM6JNlxLRhd3qg9 za25uTa52iU7q4EabidowpHyEUf0BzVtmzrZ5FqykrD4STH5RWyiS5Q0VmrF2kg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2sHIve YXhqnqIGDNQl6KG/qC0qGlmXXyNsi5d2K21Ts=; b=t18vpnXWm7VNAQ/gFxxrLu qp8GMYOkmzTr7KCWIENCh4dqRXBZ+0tm50U1ET8Ct9LECTpHRZOdxwBJ00r7+jDH 3VxSPRkRiXka2o4NXXLhGLx/GWHV3Ta8MJyffRmfzDAj8esB0Y2UfzEfdcqpR1SS VR1qpSo9SbhLNloPL8DV5y5B5Qt4jFH1wBdMrI9ULafTe6/tvvFZyQ9XedbD/Cvd GR0bMAE7iTTFApdidouPWvgA/vbHcIC2wj6qW5Rh0i0nIiUE0oT3YIXHXVjavDyb 8WRKmEVS7MLbMZqmt76anSc7dYfmsV3qOO3VbgRrprZnMA5vbj5jkPqnO8oGJFkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1958F180231; Wed, 26 Aug 2020 21:11:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <1a255764-2f48-4304-b583-5b0b7dc68b73@dogfood.fastmail.com> In-Reply-To: References: <861ab5ac-3772-a664-9da2-ffa1d1df4286@gmail.com> Date: Thu, 27 Aug 2020 11:11:12 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1c342551134e4134bfbebfae837ebad7 Archived-At: Subject: Re: [calsify] JSCalendar, recurrenceId and timezones. X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 01:11:20 -0000 --1c342551134e4134bfbebfae837ebad7 Content-Type: text/plain On Thu, 27 Aug 2020, at 05:20, Ken Murchison wrote: > I think that we have said that not all JSCalendar resources can be represented as iCalendar, but if the reverse ends up being true, I think we are making a mistake This is just a matter of encoding the data in extra JSCalendar properties if needed, so something for the JSCalendar <-> iCalendar document to specify. Either: * The source document is JSCalendar, in which case the recurrence id is just the date. * The source document is iCalendar, in which case you can save the tz of the recurrence id (if different to the event's tz) in some custom property in case you need to convert back. Neil. --1c342551134e4134bfbebfae837ebad7 Content-Type: text/html
    On Thu, 27 Aug 2020, at 05:20, Ken Murchison wrote:
    I think that we have said that not all JSCalendar resources can be represented as iCalendar, but if the reverse ends up being true, I think we are making a mistake

    This is just a matter of encoding the data in extra JSCalendar properties if needed, so something for the JSCalendar <-> iCalendar document to specify. Either:
    • The source document is JSCalendar, in which case the recurrence id is just the date.
    • The source document is iCalendar, in which case you can save the tz of the recurrence id (if different to the event's tz) in some custom property in case you need to convert back.
    Neil.
    --1c342551134e4134bfbebfae837ebad7--