Subject: [Tools-discuss] Erroneous timezone information in agenda ICS calendar

From: <[email-masked]>
Date: Thu, 15 Mar 2012 16:53:09 +0100

Hi,

I've noticed Thunderbird's Lightning complain on parsing the ICS for 
IETF meeting agenda.
It complains that " /tools.ietf.org/Olson_20110927_1/Europe/Paris " is 
not a proper timezone.

Indeed, the ICS looks like this (from 
http://tools.ietf.org/agenda/83/ics/ietf-83-mptcp-notz.ics) :

    DTSTART;TZID="/tools.ietf.org/Olson_20110927_1/Europe/Paris":20120330T112000

The fix, I guess, is to remove the double-quotes and the spurious 
'/tools.ietf.org/Olson_20110927_1/' to get something like such as:

    DTSTART;TZID=Europe/Paris:20120330T112000
    ||

The same kind of issue exists with the DTEND field, and with the TZID 
field of the ics file generated with timezone information.

(This issue has been around for some time, it just occurred to me now 
that someone should report it!)

Thanks,

-Thomas

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Mar 2012 11:21:28 -0500

Looking at RFC5545, the issue appears to be the quote marks. The ABNF production calls for paramtext, not param-value, which means that the quote marks are disallowed. 

The name itself can be literally any string that the implementer finds useful or amusing.

/a

On Mar 15, 2012, at 10:53, <[email-masked]> wrote:

> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Mar 2012 17:58:14 +0100

Thanks, Adam.

I've changed the .ics generation script to omit the quote marks; the .ics
files should be updated to use this within an hour.

Best regards,

	Henrik

---

From: <[email-masked]>
Date: Fri, 16 Mar 2012 10:02:12 +0100

Hi Adam,

2012-03-15, Adam Roach:
> Looking at RFC5545, the issue appears to be the quote marks. The ABNF
> production calls for paramtext, not param-value, which means that the
> quote marks are disallowed.

Ok, there was a syntax problem, which is now gone (thanks Henrik).

> The name itself can be literally any string that the implementer finds

How is this supposed to be interpreted by an ICS client ? If the 
implementer puts "SolarSystem/Mars", even its amusing, you don't expect 
client software to correctly understand what time you are talking about, 
do you ?

So, there still seems to be a content problem: Lightning is still 
complaining that it doesn't know about the 
"/tools.ietf.org/Olson_20110927_1/Europe/Paris" timezone. I don't know 
the ICS format, but it looks kind of legitimate for Lightning to not 
know about a timezone name with "tools.ietf.org" in it...(and even what 
follows looks suspicious).

Am I missing something ?

-Thomas

> On Mar 15, 2012, at 10:53,<[email-masked]>  wrote:
>
>> Hi,
>>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Mar 2012 10:59:48 +0100

Hi Thomas,

Inline:

> follows looks suspicious).

Yes.  The TZID in the DTSTART statement is just a reference back to the
declaration of exactly how the timezone in question is put together.  At
the beginning of the .ics file, you have something like this, which
declares a timezone (VTIMEZONE) and binds it to the TZID string:

  BEGIN:VTIMEZONE
  TZID:/tools.ietf.org/Olson_20110927_1/Europe/Paris
  X-LIC-LOCATION:Europe/Paris
  BEGIN:DAYLIGHT
  TZOFFSETFROM:+0100
  TZOFFSETTO:+0200
  TZNAME:CEST
  DTSTART:19810329T020000
  RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
  END:DAYLIGHT
  BEGIN:STANDARD
  TZOFFSETFROM:+0200
  TZOFFSETTO:+0100
  TZNAME:CET
  DTSTART:19961027T030000
  RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
  END:STANDARD

...

  END:VTIMEZONE

(There can be more than one of these in an iCalendar file, when the file
uses multiple time zones.)

The ics client isn't supposed to interpret the TZID label as such; it's
supposed to read and interpret the VTIMEZONE declaration and use the
VTIMEZONE labelled by the TZID for the DTSTART element which has that
particular TZID indication.

Speculation:  Maybe Lightning hasn't implemented proper parsing of the
VTIMEZONE component yet, and in order to get something out has taken a
shortcut of assuming that it knows about TZIDs with labels matching the
official timezone labels in the olson database.

FWIW, the naming used in the .ical files on tools is as suggested by the
authors of the fairly well-known vzic (http://vzic.sourceforge.net/)
program which converts Olson timezone database data into iCalendar
VTIMEZONE data.

Best regards,

	Henrik

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 16 Mar 2012 08:43:44 -0600

> program which converts Olson timezone database data into iCalendar

I've had this same discussion with Henrik when writing the iPhone/iPad app. While I understand the explanation offered for the custom TZID strings, I also see no upside to using this approach. There also seems to be no downside to using the Olson timezone names instead.

Thanks,
Tom

---

From: <[email-masked]>
Date: Fri, 16 Mar 2012 15:46:28 +0100

Hi Henrik,

Henrik Levkowetz :
> the beginning of the .ics file, you have something like this,
[snip]

Thanks for the explanation, it helps a lot.

The calendar on which Lightning was complaining is a calendar *without* 
timezone information ("...-notz.ics" URL), and which has no VTIMEZONE 
component.
> official timezone labels in the olson database.

Lightning does not complain if I use the other type of URL, that 
includes the VTIMEZONE component.

My question would now be: in the ICS file *without* the VTIMEZONE 
component, how is "/tools.ietf.org/Olson_20110927_1/Europe/Paris" 
supposed to be interpreted, and wouldn't it make sense to use an 
official timezone label from the Olson database, hoping that some 
clients will successfully take the shortcut you mention above ?

Thanks,

-Thomas

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 16 Mar 2012 08:49:42 -0600

> I've had this same discussion with Henrik when writing the iPhone/iPad app. While I understand the explanation offered for the custom TZID strings, I also see no upside to using this approach. Ther…

This was my argument (as Area Director) when the standard was developed. I even said that having timezone information in the record will create stale information in records that contains tzinfo for time zones where rules changed.

Events are anchored somewhere (geographically for example). The mapping between time+geo to time in other geo(*) should be possible to do using data stored in a central place, for example the Olsen databases.

So I am *strongly* supporting what you say, and even urge people that have energy to bring this back to the IETF and update the RFC's. Although of course people that have this view I have might still be in the rough part of rough consensus.

   Patrik

(*) I do not like software where I enter a city+time for an event to say the time for an event, and the application then at that point in time re-calculate the time and store the event given the current timezone. #fail The event is happening in a special timezone, and I do not want applications to "try to be smart". Timezones change.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Mar 2012 17:55:24 +0100

Hi Tomas

> timezone information ("...-notz.ics" URL), and which has no VTIMEZONE 

Ah.  Then if I recall correctly from the RFC it's a bug that there's a
TZID on the DTSTART -- that's supposed to be a floating time calendar.

I'll have a look at the code that is supposed to strip out the TZID at
once.

> clients will successfully take the shortcut you mention above ?

I think the right thing should be to do as (I recall) the RFC saying;
present this one without the TZID.

I'll check in more detail, fix as needed, and let you know.

Best regards,

	Henrik