Subject: [Ietf-calsify] issue status for 2445bis

From: lear at cisco.com (Eliot Lear)
Date: Mon Feb 26 02:37:52 2007

Dear all,

Below is a table best viewed in HTML of issues from the tracker relating 
to RFC2445bis.  The chairs would remind you that the issues list is 
closed for all but issues relating to new problems caused by the agreed 
changes, and we will scrutinize any request for such new issues 
intensely.  Issues for which there is no text will be closed in the next 
two weeks.  Some of the issues below are close to being resolved.  Issue 
54 is probably resolved with no change, for instance.  Issue 8 may have 
been handled by another issue.  You can review all issues by going to 
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.  Search is on 
the left.  No need for an account, but feel free to register if you like.

Regards,

Eliot

ID 	Activity 	Title 	Status
rfc2445bis
10 	3 days ago 	Reinhold Kainhofer: end date not inclusive 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10> 	notext
11 	4 months ago 	Reinhold Kainhofer: additional examples, VTIMEZONEs, 
RRULEs 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11> 	notext
23 	2 weeks ago 	Contradiction between UNTIL BNF rule and text 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23> 	Discuss
54 	4 months ago 	Version value bump? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue54> 	unread
63 	2 weeks ago 	Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue63> 	Discuss
67 	2 weeks ago 	Section 4.8.2.5 Duration: VFREEBUSY request 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue67> 	Discuss
68 	2 weeks ago 	DST discontinuities part 1: date-times that fall in 
discontinutities 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68> 	notext
69 	2 weeks ago 	DST discontinuities part 2: discontinuities for 
recurring event start times 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue69> 	notext
70 	2 weeks ago 	DST discontinuities part 3: discontinuities for event 
end times 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue70> 	Discuss
71 	2 weeks ago 	The "other" time discontinuity: leap-seconds 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue71> 	Discuss
72 	2 weeks ago 	Section 4.6.5 Time Zone Component: Not required when 
DTSTART is a DATE 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72> 	Discuss
73 	2 weeks ago 	Section 4.8.3.1 Time Zone Identifier: Scope of TZID] 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue73> 	Discuss
78 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART with 
TZOFFSETFROM 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue78> 	Discuss
79 	4 days ago 	Section 4.6.5 Time Zone Component: DTSTART always an 
onset date-time of an observance? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79> 	Discuss
8 	4 months ago 	Reinhold Kainhofer: Deprecate P1D or P24H? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8> 	notext

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070226/ccf405e9/attachment.htm

---

From: cmtalbert at gmail.com (Clint Talbert)
Date: Mon Feb 26 05:14:46 2007

Hello all,

I'm a bit confused by Section 4.6.5 Time Zone Component: Not required 
when DTSTART is a DATE 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue72>.  
Perhaps I missed something, but why would you NOT require a Timezone 
definition when DTSTART is a date?  Here's an example.

I am based in America/Chicago timezone
I am reading an ICS containing an all day event on Monday, Feb. 26 from 
Australia/Sydney

I would expect my application to display that event as occurring on 
Sunday, Feb 25 in the Chicago timezone (because this is when midnight, 
Monday Feb 26 occurs in Sydney).   Since 17 hours of Sydney's Monday are 
shared by Chicago's Sunday, it seems natural to display this event as 
occurring on Sunday in the Chicago time.  (In contrast, only seven hours 
of Sydney's Monday coincide with Chicago's Monday)  So it seems that the 
right thing to do would be to display this event on Sunday when viewed 
in the Chicago timezone.

I guess the point I'm trying to make is that a DTSTART without timezone 
information will only be correct in timezones that are near the same 
offset as the originating timezone of the event. 

I'm sure there are good arguments for this change, but I can't 
find/don't remember them.  Please remind me of why you decided that 
timezones are not required when DTSTART is a DATE.

Thanks,

Clint

Eliot Lear wrote:
> Dear all,
>
> Below is a table best viewed in HTML of issues from the tracker 
> relating to RFC2445bis.  The chairs would remind you that the issues 
> list is closed for all but issues relating to new problems caused by 
> the agreed changes, and we will scrutinize any request for such new 
> issues intensely.  Issues for which there is no text will be closed in 
> the next two weeks.  Some of the issues below are close to being 
> resolved.  Issue 54 is probably resolved with no change, for 
> instance.  Issue 8 may have been handled by another issue.  You can 
> review all issues by going to 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070226/0b36f8b3/attachment.html

---

From: lear at cisco.com (Eliot Lear)
Date: Mon Feb 26 07:55:47 2007

Clint Talbert wrote:
> definition when DTSTART is a date?

Consider the case of a holiday - particularly one that is observed in 
many locations.  When does it start, precisely?

Eliot

---

From: cmtalbert at gmail.com (Clint Talbert)
Date: Mon Feb 26 08:30:44 2007

> many locations.  When does it start, precisely?
Ah, yes, I see.  I thought there would be a good reason. :-)

 On re-reading the text again, I now see that you are merely saying that 
a DATE type of DTSTART does not *require* a VTIMEZONE reference. 

You are *not* saying that a DATE type of DTSTART should NEVER have a 
VTIMEZONE reference (which is how I read it this morning before my 
coffee kicked in).

I apologize for the inconvenience and misunderstanding.

Clint

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Feb 26 11:47:16 2007

Eliot,

Issue 72 is not up to date in the tracker.  Please see:

http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001486.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001487.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001488.html

I believe consensus was reached, but it's clearly your call!

Clint,

Before I brought issue 72 to the mailing list I checked RFC 2445 to find
out whether the TZID parameter could be specified on a property of DATE
value type or not. On the basis that something not forbidden is allowed,
it would be allowed.

In section 4.2.19 Time Zone Identifier of RFC 2445 it only says:

  > Description: The parameter MUST be specified on the "DTSTART",
  > "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
  > TIME or TIME value type is specified and when the value is not either
  > a UTC or a "floating" time.

It clearly brings one to believe that the TZID parameter was meant to
be used with properties of DATE-TIME and TIME value type.

We should probably clarify whether the TZID parameter should be allowed
on properties of DATE value type or not.

On one hand, if one really cares about the time zone, why isn't one
specifying a DATE-TIME value instead. On the other hand, specifying
VALUE=DATE is the only interoperable way to differentiate an "all
day event" from a regular event and thus give a hint to the client
application on how to display the event to the end user.

For what is worth, the following Google search reported 53 hits:

http://www.google.com/search?q=%22+DTSTART%3BVALUE%3DDATE%3BTZID%3D%22

Would you like to propose a text change?

Cheers,
Bernard

---

From: cmtalbert at gmail.com (Clint Talbert)
Date: Mon Feb 26 13:56:19 2007

Replies inline...
> value type or not. On the basis that something not forbidden is allowed,
This was also the way I always understood it.
> on properties of DATE value type or not.
In my opinion, more clarity rarely hurts.  You could easily make this 
more clear by stating "DATE-TIME, DATE, or TIME" in the list above. 
> application on how to display the event to the end user.
I think you've hit the nail on the head as to why this issue is 
difficult.  By all means, you *should* use times if you're sharing one 
of these events across a timezone, but most users would never think 
about that when creating an all-day event.  I haven't come up with a 
seamless way to enforce this convention yet.
> Would you like to propose a text change?
I'll leave that decision to you and Eliot.  I have the text up above, 
which is a pretty minor change.  However, it sounds like this issue was 
already addressed, and if that is the case, I don't have any desire to 
re-open it over my own misunderstanding.

Thanks,
Clint