Subject: [Ietf-calsify] DURATION and PERIOD - proposal

From: Doug at Royer.com (Doug Royer)
Date: Thu Apr 14 16:02:58 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050414/e484fef5/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Apr 15 00:28:11 2005

Doug Royer wrote:
>     1M = 60S = we ignore leap second?  I say yes.
>     1H = 60M
>     1D = 24H
>     1W = 7D

How does 1D=24H work daylight savings time? A day might not be 24H then. 
And from what I understand, also not in UTC. But as a user, i would 
expect that 1D means just that, one day.

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 10:43:55 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/9247ab18/smime-0001.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Apr 15 10:48:29 2005

Doug Royer wrote:
>> But as a user, i would expect that 1D means just that, one day.
> 
> And it still means 1D. It just looks as if it does not when in
> non-UTC TZ's.

Given that almost everybody lives in a non-utc timezone, wouldn't that 
be the target you need to aim at? Make it usable in any timezone, not 
only in utc...

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 11:01:44 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/64df3c8c/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 11:25:23 2005

Am Freitag, 15. April 2005 20:01 schrieb Doug Royer:
> Michiel van Leeuwen wrote:
> > Doug Royer wrote:
> Finish reading that email. It addressed that issue.

No, you basically say that 1D should always mean 24H. And you also say that if 
the user expects the event to end at the same time on the next day in his 
timezone, the user's expectations are wrong... 

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 11:31:03 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/71c37619/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 11:47:30 2005

Am Freitag, 15. April 2005 20:30 schrieb Doug Royer:
> Reinhold Kainhofer wrote:
> > No, you basically say that 1D should always mean 24H. And you also say
> > that if the user expects the event to end at the same time on the next
> > day in his timezone, the user's expectations are wrong...
>
> I said no such thing and I have no clue why you think I did.

Implicitly, see below.

> I said when you do the math in UTC - everything works. A day
> is never 25 or 23 hours, 

Huh? Sure, for me (as a user) March 27, 2004, is only 23 hours long (in Europe 
where DST starts at that date).
You say that by definition a day is 24 hours, and from this, of course the end 
time is not always the same. 
The user, however, thinks differently (see below). For a typical user 1D means 
same time on the next day. Now you say, that the result with the 24 hours 
duration is always correct, and although the user understands a duration of 1 
day differently and expects a different result.

Basically, it boils down to two different definitions of one day. Does a 
duration of 1 day mean:
-) one day (same time, different date) in absolute time coordinates, but not 
necessarily in the time zone of the event? This definition is equivalent to a 
duration of 24 hours. The end time in the user's local time is not always the 
same.
-) one day (same time, different date) in the user's local time? The duration 
is not constant, but the end time is the same for all occurences.

You think using the first definition, the user (intuitively) thinks in terms 
of the second definition.

> it just appears that way when you 
> look at a clock that was changed.

Yes, but 
1) the users think in time and date separated, so one day duration means: 
Increase the date by one, leave the time untouched.
2) the user doesn't think in absolute time coordinates. Almost all users think 
relative to that clock, which was changed. 

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/37fe7697/attachment-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 11:55:36 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/1f498337/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Apr 15 12:20:18 2005

Doug Royer wrote:

> Show an example that fails when you do the conversion to UTC, then
> the duration math, then the conversion back to the TZID.

in javascript:

js> d=new Date("March 27, 2005 0:0:0");
Sun Mar 27 2005 00:00:00 GMT+0100 (CET)
js> d.setUTCDate(d.getUTCDate()+1);
1111964400000
js> d
Mon Mar 28 2005 01:00:00 GMT+0200 (CEST)

In other words, the end date is not 00:00 anymore, like the user would 
expect.

> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 12:29:23 2005

Am Freitag, 15. April 2005 20:55 schrieb Doug Royer:
> Which is why I showed converting it back to the users local time zone.
>
> And it matches what the user expected.
>

Take an event in CET (DST starts on March 27, 2005) that starts at 01:30 CET 
on March 27 and lasts one day. The user expects this to end at 01:30 CEST on 
March 28.

Now do the math in UTC. The event starts at 00:30 UTC on March 27 and so ends 
at 00:30 UTC on March 28. That time, however, is 02:30 in the user's new time 
zone. So in this option, the event ends at 02:30 CEST on March 28, while the 
user expects it to end at 01:30.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/58091c7d/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 13:33:40 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/0b24cf3e/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 13:41:04 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/6ec7b5d7/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 14:32:54 2005

Am Freitag, 15. April 2005 22:40 schrieb Doug Royer:
> With 2445 rules, 2:30 or 1:30 could be the correct answer.
>
> So, again, lets deprecate 'D' and the Organizer can set
> the explicit real duration of when the Attendee should
> think that it is over. The Organizer is free to remember
> in its own cal-store that it means 'day' and not '##S',
> '##M', or '##H'.

It's also the attendee that needs this meta-information, e.g. for 
counter-proposals.

Take a hospital where the 24h-shifts (they're called "24h", although they are 
really 1D events, which last until the same time on the next day, typically 
from 8am until 8am on the next day, even across DST switches) are organized 
with iCal and iTIP. 
The manager plans one doctor's shift on March 26, 2005, 8am CET until March 
27, 8am CEST (duration is 23 hours). He sends out the object, but the doctor 
can't take that shift, moves it one day (March 27, 8am CEST until March 28, 
7am CEST) and sends back that shift. Since the duration of the original event 
was 23 hours (as opposed to 1D, which you want to remove), the 
counter-proposal also has only 23 hours, although the shift would really have 
23 hours. Thus, there will be one hour in the hospital's timetable without a 
doctor.

I think 1D is exactly the solution to the two different meanings of "one day", 
which I elaborated in my previous mail. If you want to ensure that the event 
always lasts 24 hours (and possibly has a different end time), use PT24H. If 
you want the event to end exactly at the same time on the next day (and 
possibly has a different duration), use P1DT. In the latter case the TZ of 
the event is also relevant. 

To me PT24H means: Use time arithmetic to calculate the end, and P1DT means: 
Use date arithmetic and leave the time untouched (if possible).

We just need to make sure to clearly mention that in the standard (and solve 
the border-line cases when an invalid/non-existent or duplicate end time 
would result.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/da1e6f12/attachment-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 15:44:27 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/37150266/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 16:11:17 2005

Am Samstag, 16. April 2005 00:44 schrieb Doug Royer:
> So:   +PT1DT2H would be add 1 to the 'date' part, plus 2 hours ?
>
> Editing the relevant part of my proposal it would become:
>
> To find the end time for an appointment, (DTSTART/DURATION
> or RDATE/PERIOD-start):
>
>   For 'wW' - add 'w*7' days to the 'date' part in its original TZ
>       'dD' - add 'd' days to the 'date' part in its original TZ
>       'hH' - add 'h' hours to the 'time' part in its original TZ
>       'mM' - add 'm minutes to the 'time' part in its original TZ
>       'sS' - add 's' seconds to the 'time' part in its original TZ
>
>    Normalize the date (wrap seconds, minutes, hours, date, month,
>    when needed).
>
> Does order of addition matter ? I don't think so, I have to think about
> that.

Order does matter. In particular, there's a difference if a time zone shift 
happens during the D part (in which case it's basically ignored) or during 
the H part. 

E.g. take a DTSTART at 01:00 CET (00:00 UTC) on March 27, 2005 (DST begins on 
March 27), and a DURATION of P1DT6H. 
-) If you first add the one day, you have 01:00 CEST on March 28, plus 6H 
gives 07:00 CEST on March 28.
-) If you first add the six hours, you'll have 08:00 CEST (since the hour from 
02:00 to 03:00 is skipped). If you then add one day, you'll end up with 08:00 
CEST on March 28.

Intuitively, I'd first add the larger interval. I.e. first add the W, then the 
D, then the H, M and S parts of the duration.

> Or do they need to be normalized as added? Start with 'S', then 
> 'M', 'H', 'D' ?

I'd say the other order.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050416/fa278abe/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Apr 15 16:52:18 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/fc50f17a/smime.bin

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Sat Apr 16 12:14:04 2005

>    Normalize the date (wrap seconds, minutes, hours, date, month,

I think this isn't what people are saying, or at least it needs to be
explained better -- 'in its original TZ' is ambiguous.  It's correct for h,
m, and s, but w and d should add to the 'date' part, *leaving the time part
untouched*.

Many time packages, if you start with (e.g.) 2005-04-01 00:00:00 EST, and
add 7 to the date field (generating 2005-04-08 00:00:00 EST), and normalize,
will give 2005-04-08 01:00:00 EDT.

The important difference here is that when you add W and D, you add to the
date field and then calculate the appropriate TZ offset; when you add H, M,
or S you add to the time field and then *adjust the time part* for the
appropriate offset.  This means that PT8H always means 8 actual hours, not
"add 8 to the hour field."

This needs word-smithing for the standard; I don't feel like I've explained
this very well.

> that. Or do they need to be normalized as added? Start with 'S', then 
> 'M', 'H', 'D' ?

I agree with Reinhold that it should be largest-component-first, i.e. start
with 'W'.

I believe this is equivalent to (W and D), (H and M), and (S), with (S) only
needing to be separated if you're handling leap seconds, since weeks are
always a constant number of days and hours are always a constant number of
minutes.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 16 12:44:03 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050416/0388cb75/smime.bin