[Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter specified on DATE property

[douglm at rpi.edu]

I suppose I agree with reservations...

>From a ui perspective it's useful to be able to flag something as an all
day event without the precision implied by setting the start and end to
specific times.

For personal events it's probably not an issue. However, when trying to
use rfc2445 objects to advertise public events it's more problematical.

For example, we have graduation at RPI. It doesn't start at midnight and
end at midnight but for all intents and purposes it's an all-day event.
Some of it is webcast. If we mark it as an all day event without a
timezome the New Zealand parents will tune in 12 hours out (assuming they 
trust calendars and timezones).

One solution is to allow a TZID on a DATE. Then we interpret the date in
the intended timezone - whatever our personal timezone. This appears to
be a matter of just firming up an omission in the rfc.

Also it doesn't disallow 'floating' dates i.e  a DATE without a TZID so
we can still say - all day on March 15th is my birthday (yes it is)

Another option is to flag date/time as being really all day - microsoft
have an x-property which does just that. This would work but seems more
complex.

All-day already has some implied fuzziness to it which is useful and
perhaps we should extend that rather than trying to add fuzziness to a
precise definition of time implied by DATETIME

==============Original message text===============
On Wed, 27 Jun 2007 13:15:51 EDT Bernard Desruisseaux wrote:

Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
use of the TZID parameter on DATE properties. This section specifies
when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
values, but says nothing about DATE.

Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
discuss the TZID parameter at all.

I'm bringing this up since Mozilla Sunbird specifies the TZID parameter
on DTSTART and DTEND of "All Day" events. For instance, here's an All
Day VEVENT created by Mozilla Sunbird with my time zone set to
Asia/Shanghai (UTC+08:00):

BEGIN:VEVENT
CREATED:20070627T160534Z
LAST-MODIFIED:20070627T160607Z
DTSTAMP:20070627T160650Z
UID:d9a9e2e4-4123-4b06-8dca-c10f791f8700
SUMMARY:All Day Event June 28th 2007 (Asia/Shanghai UTC+08:00)
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070628
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070629
END:VEVENT

To find out whether Mozilla Sunbird actually cares about the TZID
itself I changed my time zone to America/Montreal (UTC-4:00). Given
that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
June 27th, 12:00 (noon) America/Montreal I was wondering if this
All Day event would be displayed on June 27th, 2007. It turns out
that Mozilla Sunbird still displayed the event on June 28th.

    Note: If you want to try this yourself with Mozilla Sunbird,
    you'll actually need to change the time zone of your OS to
    match the time zone you configured in Mozilla Sunbird.  Else
    Mozilla Sunbird will end up creating the All Day event on the
    wrong day altogether. For instance, if you configure Sunbird
    with Asia/Shanghai but have your OS configured with
    America/Montreal and create an All Day event on June 28th, 2007,
    Mozilla Sunbird will create an All Day event that start on
    June 29th!

While iCalendar currently doesn't forbid the use of the TZID parameter
on DATE value properties, it certainly doesn't look like it was ever
meant to be used. If one wants to ground a given DATE to midnight of
a specific time zone I believe one should simply use a DATE-TIME value.

I propose to change the following statement in section 4.2.19 Time Zone
Identifier, from:

 > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
 > properties whose time values are specified in UTC.

to:

 > The TZID property parameter MUST NOT be applied to DATE properties,
 > and DATE-TIME or TIME properties whose time values are specified in
 > UTC.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
===========End of original message text===========


-- 

Mike Douglass                           douglm at rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies
518 276 6780(voice) 518 276 2809(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180