dougrday/icalvalid — Issue #5: X-WR-TIMEZONE
Author: dougrday
Created: 2011-10-11 15:47:32+00:00
State: open
Labels: Bugs

[From Jon Udell]

There's more. We're starting to be in a position to characterize the iCalendar ecosystem as a whole. I made the attached file to help me reason about an issue I've just run into. It seems that X-WR-TIMEZONE has crept into the ecosystem in a way that's undefined and poorly understood.

Consider these:

(1) http://icalvalid.cloudapp.net/?id=634539383310479792 (from http://jonudell.net/data/t_berkeleyside.ics)

(2) http://icalvalid.cloudapp.net/?id=634539383683891002 (from http://jonudell.net/data/t_berkeleyside2.ics)

Both are perfectly valid according to the Validator (and the spec). But if you load both of those calendars into both Google Calendar and Hotmail Calendar, and your calendars are set to Eastern time like mine, you'll see this:

Google:

Hotmail:

It seems that X-WR-TIMEZONE, in the absence of VTIMEZONE, has come to mean: interpret the X-WR-TIMEZONE value as an Olson name, construct the corresponding VTIMEZONE, and make all the dates refer to that VTIMEZONE.

[Doug]
Eww, just eww. I’ve noticed the use of X-WR-TIMEZONE in calendars, but never really sat down to figure out what it means and how it affects calendars. Your interpretation of its behavior is useful to help us decide how to validate against it.

The green calendar is derived from the pink one by some code that implements that rule. It is a completely standard calendar that will work the same in Hotmail Calendar, which doesn’t see X-WR-TIMEZONE as a trigger for that sort of rule, and Google Calendar, which evidently does.

Should X-WR-TIMEZONE become standard? Maybe. It would make life easier for iCalendar producers, who could just mention a timezone rather than having to specify one. [Doug] Unfortunately, without including the actual time zone information in the calendar (i.e. via VTIMEZONE), you can’t be sure that the date/times you’re representing are accurate, even when using X-WR-TIMEZONE. For example, if you’re on a Windows XP machine that hasn’t been updated in 5 or 6 years, your system time zone information will be inaccurate. However, if the VTIMEZONE were included in the calendar, it would remain accurate, even on an older machine with out-of-date time zone defintions. Also, in order to interpret X-WR-TIMEZONE, you’d also need to be in an environment where interpreting Olson time zone is realistic (easy on Linux, harder on Windows). I know a global, online time zone registry is in the works, but I don’t think it’s a point where it’s useful, yet. But the situation right now seems bad. I can’t find much discussion of X-WR-TIMEZONE anywhere online. What I do see is people doing what I’m doing, which is inferring a rule based on observed behavior. But that leaves many unanswered questions. What does an iCalendar consumer do when both X-WR-TIMEZONE and VTIMEZONE are present? What if X-WR-TIMEZONE is present, VTIMEZONE is absent, but DTSTART already mentions a TZID? Etc. [Doug] I think VTIMEZONE should always trump X-WR-TIMEZONE, because it is defined in the standard. That said, I think for validation purposes we should always warn against using X-WR-TIMEZONE. And, in cases where X-WR-TIMEZONE is used alongside VTIMEZONE, display it as an error, since it would be difficult to guess how any calendaring application would interpret it.

Anyway the practical motivation for me is that I have a hub in Berkeley, and one of its feeds comes from a producer who got the idea that X-WR-TIMEZONE:America/Los_Angeles without any VTIMEZONE is the right thing to do. Hey, it works in Google, must be right! So I might go ahead and do that too because the users of the hub won’t care about what the spec says, they’ll care that that the event is 5:30 local time, not 8:30.

Now here’s the interesting thing about the attached spreadsheet, both for a service like elmcity and for the validator. It gives us some data to help us reason about ecosystem. From my POV, I can see that 100 of 600 producers evidently think that X-WR-TIMEZONE alone is the way to go. (Sort by has_x_wr_timezone=TRUE and then has_vtimezone=FALSE.) That tells me that the practice is very widespread. I still need to decide whether to jump on the bandwagon, but at least I have some context. (I can also see that 30 of the 100 use X-WR-TIMEZONE without VTIMEZONE, but specify times as UTC. What the heck is that supposed to mean?) [Doug] From my perspective, it doesn’t mean anything. UTC is UTC, time zone or not. I think some producers use X-WR-TIMEZONE because they’ve seen others use it, and don’t want to accidentally break CUAs like Outlook or Google Calendar.

From the validator’s POV, it was always the intent not only to validate against the spec but also to give guidance about the state of the ecosystem. This kind of data can help the validator do that. Based on what I’ve learned I would recommend that it at least mention, when seeing X-WR-TIMEZONE without VTIMEZONE, that such usage will make your calendar dependent on a nonstandard feature of the consumer. But it would be awesome to also be able to point to data indicating how broadly the ecosystem has decided to bet on that nonstandard feature! [Doug] I agree it’s a great idea to display information relevant to the current ecosystem. In addition, I think we’ve added the validator to the ecosystem in an attempt to influence it in a positive direction. I see this as a good opportunity to do so – our validation results can help publishers create more conformant calendars. Thanks for bringing this up! I think I’ll add this as an issue to github as well.

FYI – if you have any issues that you’d like fixed in the validator, adding them as an issue to github will ensure I don’t forget about them as I go. Hopefully, we can get others interested in contributing to icalvalid as well, in which case they’ll be able to see each issue on guthub also.

Jon

[Doug]
Thank you!