iCal feed not honoring timezone or Daylight Saving Time

Exact same problem here. (And I'm also in UTC+1.)

Same problem here. My site and I are both UTC-5 and all my events are imported into Outlook 5 hours too early. Thanks for any help on whether I'm missing a configuration step or if this is just a bug.

@wusel posted steps to reproduce this in #1467830: Step-by-step instructions: Timezone-handling is wrong / editing and importing of date-fields are different.

Same problem here. This seems like a bug to me, site and I are both UTC-5 and all my events are 5 hours early. Looks like it's not putting in a correct offset when building the .ics file.

Bumping to critical. Seems appropriate here.

My personal fix, if it's any use to anyone:

if ($event['all_day']):
  print "DTSTART;VALUE=DATE:" . $event['start'] . "\r\n";
else:
  $objDate = date_create_from_format('Ymd\THis',$event['start']);
  $unixDate = date_timestamp_get($objDate);
  $eventstart = gmdate('Ymd\THis',$unixDate);
  print "DTSTART:" . $eventstart . "Z\r\n";
endif;
if (!empty($event['end'])):
  if (!empty($event['all_day'])):
    print "DTEND;VALUE=DATE:" . $event['end'] . "\r\n";
  else:
    $objDate = date_create_from_format('Ymd\THis',$event['end']);
    $unixDate = date_timestamp_get($objDate);
    $eventend = gmdate('Ymd\THis',$unixDate);
    print "DTEND:" . $eventend . "Z\r\n";
  endif;
endif;

This should replace the relevant lines in date-ical-vevent.tpl.php. I'm sure it's not the recommended way of doing things but it appears to do the job.

Should date_ical be depending on an iCalendar library rather than theme functions? That could solve the timezone problem.

I worked a little on the iCal module in D6 which depends on iCalCreator.

KarenS, was that approach considered?

There's also qCal which I haven't used at all.

Here is the vcalendar 2.0 standard.
http://tools.ietf.org/html/rfc5545#section-3.2.19

With respect to time zones,

Description: This 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
neither a UTC or a "floating" time. Refer to the DATE-TIME or
TIME value type definition for a description of UTC and "floating
time" formats. This property parameter specifies a text value

Example:
DTSTART;TZID=America/New_York:19980119T020000

So I don't think the solutions in #6 are appropriate as they strip out the time zone information necessary for conversions to everyone's local calendar. It seems a more appropriate solution is being able to inject this information into the DTSTART and DTEND lines.

Actually in the date-ical-vevent.tpl.php file it states that $event['timezone'] can be used. But it's not yet set in date_ical_plugin_row_ical_feed. It seems like it's very close to being there around

// Set the item date to the proper display timezone;
$start->setTimezone(new dateTimezone($item['timezone']));
$end->setTimezone(new dateTimezone($item['timezone']));

So either we need an $event['timezone'] = $item['timezone']; or something equivalent.

Quick followup -> http://tools.ietf.org/html/rfc5545#section-3.3.5

FORM #2: DATE WITH UTC TIME

The date with UTC time, or absolute time, is identified by a LATIN
CAPITAL LETTER Z suffix character, the UTC designator, appended to
the time value. For example, the following represents January 19,
1998, at 0700 UTC:

19980119T070000Z

So timezone may not be required if it's being specified by the UTC time here.

I ended up adding the 'timezone' variable in the date_ical_plugin_row_ical_feed by using the $item['timezone'] variable. I then went in to the tpl.php and adjusted the formatting to strip the Z and add the TZID variable.

Alternatively, the date can be left as a UTC timezone and there has to be a correction on the DTSTART and DTEND variables as they output using the local timezone time (e.g. a time of 5PM mount time comes out at hour 17 while still claiming to be UTC time zone, which should be 8+ hours ahead).

Thoughts?

Here is a patch with my changes listed within, but I'm waiting to hear back from KarenS whether she wants to use this approach or not.

The patch in #11 does not apply. Here is a slightly revised version that does.

Rick, it looks like you put date_ical in /modules of your drupal root and then made a patch against your Drupal root. That directory should only be used for core modules. See http://drupal.org/documentation/install/modules-themes/modules-7

Also I removed the "2" in

print "2DTSTART;TZID=" . $event['timezone'] . ":" . $event['start'] . "\r\n";

I think that was just a typo.

This patch seems to get things working in that my events now show up at the correct times on my desktop calendar program after I pull them from a feed. However I'm still skeptical that this module is taking the best approach to cover the iCalendar spec. I think it'd be cleaner to rely on a library and have less Drupal-specific code.

Hey Stevector.

Yes the 2 was a typo :) I was debugging and trying to verify the template was being pulled.

As for the incorrect patch, I gotta get better at just checking out the module and applying it there so I get a clean patch.

Can you expand on your recommendation for a library versus a module? I don't think this is going to leave contrib anytime soon... and I think keeping it as a module does allow one to change things to their liking. My hope is that this patch (and your modifications!) bring the out-of-the-box version to a decent implementation of said standard.

I'm suggesting a module that relies on a library. The ical module in Drupal 6 used objects based on an external library to generate VEvents, etc rather than tpl files.

http://drupalcode.org/project/ical.git/blob/refs/heads/6.x-1.x:/ical.mod...

I'm curious if this approach was considered when date_ical was written. I don't know enough about the iCalendar spec to say whether such an approach is necessary or worth the refactor time.

I kinda have a different opinion. I like tpl's because there is always the edge cases that you have to deal with an hacking the module and maintaining said modifications with each upgrade is a pain in the arse!

Getting closer using the patch in #12... but still a few problems:

1. Line 29 says 'start' where I believe it should say 'end'. Can someone reroll? (I'm still developing my patching skills, sorry.)
2. In Outlook on Windows, daylight saving time is not being honored — is this an Outlook-specific problem? So if I export an event that is from 8:15 – 9:15 am, the iCal file correctly shows the following:
   

   DTSTART;TZID=America/New_York:20120427T081500
   DTEND;TZID=America/New_York:20120427T091500

   but it imports into Outlook as 9:15–10:15 am. Any ideas how to fix this?

3. Also, I changed the version on the issue to clarify that this needs to be applied against the dev version.

Glad to see the conversation's got going! I think I'll stick with my own fix for now, until any fixes are committed to the module. Just to respond to what #6 said, I believe my fix, while it does strip the timezone originally attached to the date (and is pretty convoluted!), does faithfully render the date in UTC which means it'll appear correctly in whatever timezone you are in. So unless you really need the original timezone it is still a valid fix. But I'm still a complete newbie at this so happy to revoke that if anyone discovers otherwise :)

I changed line 29 and applied the patch from #12. My calendar.ics now looks correct; for example:

BEGIN:VEVENT
UID:calendar.4.field_event.0
SUMMARY:My Meeting
DTSTAMP:20120409T165740Z
DTSTART;TZID=America/New_York:20120418T190000
DTEND;TZID=America/New_York:20120418T190000
URL;VALUE=URI:http://mysite/my-meeting
DESCRIPTION:-----------------------------------------------------------------------------
END:VEVENT

When I subscribe to iCal on my iPhone, all's well. When I subscribe using Google Calendar, however, events appear 6 hours earlier. What's more, Google's timezone for the subscribed calendar says UTC, not America/New_York.

Seems like the most compatible fix would be to convert local (drupal server) time to UTC.

Replying to #17.

I think stripping the timezone can lead to problems with daily savings... because not all timezones convert and that could surprise you if left unchecked!

A slight correction to #12. I had mistakenly left 'start' in the DTEND line of the tpl. So I simply edited the patch from #12 by hand to correct.

Although I think the timezone correction in #20 is correct, it doesn't seem to validate against this validator http://icalvalid.cloudapp.net/Default.aspx

This will probably need to be set to need work... but I'll investigate further.

Hey everyone,

This timezone thing may be a no go. Not only do you have to set a tzid, but in order to be completely compatible with the spec, you need to include a vtimzeone for each possible entry... and there are a TON of them.
http://tzurl.org/zoneinfo/

I may just give up an use strict UTC at this point.

Thanks for the patch in #20, it's worked almost perfectly. Except it's an hour off.
My Drupal site is setup to use America/Vancouver -700
Which makes everything on the site show up at the proper times, but my iCal files are an hour off. 9 am becomes 10 am on the iCal.

If I change it to -800, then the iCal files work, but all the times on the site become an hour earlier.

@VanD
Without all the timezone definition files for daylight savings, etc... it this idea may be a no-go.

I'm a bit confused here. I just checked the database and it looks like the date field stores the information in GMT time already. Does Drupal present it offset when the ical module accesses it? It looks to me like the original problem was that Date iCal said that it was GMT but that it had placed the offset time in the file it built.

I say let the ical info be in GMT and let the client reading the ical calculate the offset based on it's local TZ data.

@aarailfan
I'm interested to know this too. If Drupal can figure out the correct timezones, why can't date_ical?

Many thanks to rickmanelius for the patch in #20. My calendar feeds now work as I expect them to.

I think I have a fix.

If I'm correct in that honoring the timezone (e.g. placing it in the vevent.tpl.php output) will be simply too difficult because of the daylight savings, time zone entries (see #22) and the validation issues (see #21), then we need to stick with strict UTC times for now and simply rely on the application to do any local time zone conversions off of UTC.

This appears to be assumed in date ical's date-ical-vevent.tpl.php because it's using $date = date_now('UTC'); and also appending the 'Z' value at the end of all datetime values. And as per #10, the 'Z' denotes UTC.

The problem is that date_ical_plugin_row_ical_feed.inc converts out of UTC and into the specified timezone with these two lines.
$start->setTimezone(new dateTimezone($item['timezone']));
$end->setTimezone(new dateTimezone($item['timezone']));

Since we can't easily add the timezone data in order to make this work, I suggest we comment them out so we retain the data in UTC format (which is what the vevent.tpl.php is expecting).

//$start->setTimezone(new dateTimezone($item['timezone']));
//$end->setTimezone(new dateTimezone($item['timezone']));

Submitting a patch below

I can confirm that the patch from #28 is working for me. Thanks rickmanelius.
7.x-1.1 with a fresh checkout, on Drupal 7.14 with UTC-7

Cheers and thanks.

Awesome! Patch in #28 fixed my problem of current events (during Daylight Saving Time) being 1 hour off. I didn't test any more thoroughly than that though. Thanks @rickmanelius!

You both are more than welcome. Seeing as we have two positive reviews (#29 and #30), I'm setting to RBTC to place this higher in KarenS queue and we'll see if this is the correct approach or not.

Patch from #28 is working for me as well. All my events now show the correct start time.

Sorry to burst the bubble, but this approach doesn't work with repeating dates, the repeating time needs to be given in the timezone of the event, so that it repeats at a consistent time throughout the year, even through daylight savings, so from the perspective of UTC it doesn't repeat with the same time.

It's really nasty that we need to effectively define our timezones in the ical feed, but that's the spec. I wonder if there's a library that could do just that part for us?

Bummer. Unfortunately the time zone definition files look pretty weighty and the only publicly available ones I saw (buried somewhere in the links above) didn't go through 2012 in the various countries.

I know the date modules and/or drupal core seems to be able to handle this, so there has got to be some library available to get this sorted out!

In that case, we'll have to start with #20 and get in the timezone libraries...

You know, actually, I'm going to mark this back as RTBC, it's not the perfect solution, but it works for everything except repeating dates, which might add significant complexity, and thus time to getting a fix done. I'd say, get this fix in, and then fix 'properly' later with the timezones stuff.

PHP actually has built in support for getting a list of daylight savings switchovers in DateTimeZone::getTransitions btw. Which is the hardest part of getting the timezone into the iCal file.

I wholeheartedly agree. We can get 95% there now, and create a new ticket to get that last 5% (if it's needed).

Thanks for the RBTC :)

Path from #28 works great, except for all day events that stopped working as such.

Dates in an all day event from before patch:

DTSTART;VALUE=DATE:20120622
DTEND;VALUE=DATE:20121001

The same event after patch:

DTSTART:20120621T230000Z
DTEND:20120929T230000Z

Which means that iCal now shows this as 24 hour event instead of an all day one.

Hmmm. Setting to needs work until I have time to come back (or if anyone else wants to jump in)

My all-days don't show as 24 hour, but as events at midnight rather than all day.

From reading the standard, at least according to random reference listed below:

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

The DSTART is specified in the following manner via the template:

<?php
$date = date_now('UTC');
$current_date = !empty($event['current_date']) ? $event['current_date'] : $date->format(DATE_FORMAT_ICAL);
print "DTSTAMP:" . $current_date . "Z\r\n";
?>

This is what is called absolute time and by using UTC, you are guaranteeing the timezone to always be correct, if the client can do simple math.

There are other approaches:
- Floating Time
- Local Time + Offset

I am currently of the belief that the problem happens because the timezones are reported via local time while the DTSTART is defined via absolute (utc) time.

I suggest changing the values to UTC.

References:
- http://www.kanzaki.com/docs/ical/dateTime.html

As far as comment #37 is concerned:

The "all day" problem happens because of two reasons:
1) Events that span multiple days should probably be treated as all days (fixed in new patch) and the date_is_all_day() test does not check multiple days.
2) The date_is_all_day() test can fail for datetime dates because the hours and seconds is included. The way in which it can fail is a result of the timezone adjusments. The timeszones must be adjusted to UTC after the date_is_all_day() test.

The patch only solves reason #2 because I think reason #1 is arguable.
This patch also performs fix from comment #40.

Forgive me if I'm missing something obvious (date/time stuff does my head in), but shouldn't we only do the UTC adjustment for non-all-day events? This results in the expected behaviour for me (here at UTC+10), anyway.

I agree, this should be worked in parts. Let's get this closer to being better, instead of arguing that it's not perfect. The DST / repeating events bug existed all through D6 after the switch to using UTC in the feeds (and is still there), so lets just get this working in the 90% case and fix the rest of the issues as we go.

I'm using patch #42 to get there for now, would be nice to land this or some other related patch.

I ended up adding the 'timezone' variable in the date_ical_plugin_row_ical_feed by using the $item['timezone'] variable. I then went in to the tpl.php and adjusted the formatting to strip the Z and add the TZID variable.

Alternatively, the date can be left as a UTC timezone and there has to be a correction on the DTSTART and DTEND variables as they output using the local timezone time...

Rick, I have started playing with Date iCal to get my dates into my Google calendar, and I would definitely prefer your first approach, i.e. having TZID as explicit values in an iCal feed. This is much more logical and convenient for people like me, who travel across timezones and share their schedules with people in various timezones. Imagine e.g. the following scenario. I am going to come to NYC, where I will be at a conference from 9 AM to 5 PM. I enter that conference as a date in my calendar, and it is exported into an iCal feed. That iCal feed is imported into my Google calendar. My New York-based colleagues check that calendar, to have a cup of coffee after my conference there. In this situation, it would be more convenient if they see my conference event as 9 AM to 5 AM New York time rather than 1 PM to 9 PM UTC. With the current Date iCal implementation, I would have to edit my Google calendar manually for my friends to see it in their local timezone.

...I believe my fix... does faithfully render the date in UTC which means it'll appear correctly in whatever timezone you are in. So unless you really need the original timezone it is still a valid fix.

See my previous comment. I believe I am not the only person who does need the original TZ in exported calendars.

I personally think that using UTC is always correct, because there are no adjustments to make on the server.

When time is reported as UTC on the ical, then it is left for the client to tell time based on its own timezone, such as UTC+10.
This is usefull for people who travel, their client should know when their given timezones and the ical never has to change a thing.
(Thus the server time is always correct and any timezone adjustment mistakes would be the fault of the client software).

This is particularly useful with clients, such as a cell-phone, that uses GPS coordinates to determine its local timezone offset down to the seconds.

Perhaps an additional setting in the iCAL calendar view settings would be a useful addition for those who want to change or tweak how the data is presented, such as with this UTC vs localtime argument.

Perhaps an additional setting in the iCAL calendar view settings would be a useful addition for those who want to change or tweak how the data is presented, such as with this UTC vs localtime argument.

OK, the more choice the better :).

When time is reported as UTC on the ical, then it is left for the client to tell time based on its own timezone, such as UTC+10.
This is usefull for people who travel, their client should know when their given timezones and the ical never has to change a thing.

I provided an example of people getting my schedule from my Google calendar shared with them. When Google Calendar imports an iCal feed without TZIDs, it just shows time as is, i.e. UTC, although _I entered my New York schedule as New York local time_ in the very first place. Would you say it is more convenient for those people in New York (or Warsaw, etc.) to calculate the local time manually? ;)
For client software, almost nothing would change; it would just apply the standard values for TZ shift. I.e., imagine a client application that sees 17:00 Europe/Kiev DST. It "knows" that Europe/Kiev DST is UTC+3 (any doubt? ;)). When that application needs to convert it to New York DST (i.e. EDT), which is UTC-4 (again, is there any doubt about that fact? ;)), it will do the math and produce 10:00 EDT, and this result would not depend on whether it all started with "17:00 Europe/Kiev DST" or "14:00 UTC".

This is particularly useful with clients, such as a cell-phone, that uses GPS coordinates to determine its local timezone offset down to the seconds.

This raises another thought. You imply here that people are always interested in getting time as the local time (_their_ local, i.e. "local local", not another place's local). This is not always the case. Imagine another scenario. Here I am, sitting in Kyiv (aka Kiev), and ordering my train ticket from Warsaw to Berlin. I had entered my Warsaw schedule in Warsaw local time, and I would like (ideally :)) to be able to see it exported, imported into my other calendars, shown in various clients etc. as Warsaw local time (remember: I am now looking at Polish Railways website, their train schedule being local time, not UTC :)). However, for me to be able to see it that way, TZID has to be explicitly exported. (Otherwise I would have to calculate it manually, in my head: my software client in Kyiv would not have a chance to know that now I need my schedule in Warsaw local time, i.e. the way I entered it, rather than Kyiv local time.)

To make it short: I support thekevinday's idea of selectable options, but I definitely believe that one of those options shoild be "Export time in the iCal view exactly as entered in the calendar (i.e. with TZID)".

I have been using Rick's patch from #20; it works nicely here, and the result validates against http://icalvalid.cloudapp.net/Default.aspx. Many thanks to Rick.

While I thank you for the feedback with #20, the problem is it doesn't account for daylight savings and that requires a whole host of extra support files/libraries to handle.

I actually vote for the solution in #35... that is to temporarily force to UTC just so we get this first win in... and then spin off a new ticket to add in the specific time zones with daylight savings libraries (a much larger task).

I think my patch in #28 is actually trumped by #40, which explicitly declares the UTC time and is therefore a better starting point to then take it to the patch in #20 WHEN the supporting libraries are made available.

I actually vote for the solution in #35... that is to temporarily force to UTC just so we get this first win in... and then spin off a new ticket to add in the specific time zones with daylight savings libraries (a much larger task).

I would probably agree, as long as this temporary solution does not result in TZ export in iCal being postponed until Drupal 9 :).
In the meantime, I think I personally will still try to continue using your patch from #20. At least now it does not seem to produce any problem with DST for me.

#1686642: Combo Patch for 1460058, 1608738 and 1608836 cross-references this issue.

Maksym Kozub, your position seems to be based on the premise that if you have a fully valid, correctly-formed iCal feed that has times expressed in UTC, that Google will only display it in UTC.
a) Have you tested that this is actually the default behaviour if you import an iCal feed into a new Google calendar account that has not had a timezone specified, if it is even possible to set up a Google calendar without selecting a timezone? (Does Google detect the timezone of the location you are browsing from and set that as a default?)

b) Have you tested what happens if you import an iCal feed into an existing Google calendar account, when it already has a timezone set by the user?

This is clearly a complex issue—certainly creating iCal feeds with full VTIMEZONE records would be—so we don't want to add to the complexity with theoretical problems if they haven't actually been demonstrated to exist through testing. Just wondering if your New York coffee example might be one of those. :)

I am currently of the belief that the problem happens because the timezones are reported via local time while the DTSTART is defined via absolute (utc) time.

I wondered the same thing myself... while on the face of it, it would seem from the spec that it is ok to format different date-times in different timezones, and this should be handled correctly, it doesn't seem that unlikely that this might be why Google calendars are falling back to UTC for instance. (This would, of course, be easy to test.)

Patch in #42 fixed the issues for me. Nice work.

Haven't got any recurring appointments to worry about. :) That's an incredibly simple patch too, so anyone who needs this now and isn't comfortable applying patches the automatic way should just manually make the change themselves on the basis of looking at the contents of the patch file... :)

Duncan, thank you for your reply.

a) Have you tested that this is actually the default behaviour if you import an iCal feed into a new Google calendar account that has not had a timezone specified, if it is even possible to set up a Google calendar without selecting a timezone? (Does Google detect the timezone of the location you are browsing from and set that as a default?)

I did not test it before, but now I have done it. It is impossible indeed to have no timezone specified. I have created a new Google account from scratch, and as soon as I visit Google Calendar for the very first time and try to do anything, a modal window appears forcing me to select a timezone.

b) Have you tested what happens if you import an iCal feed into an existing Google calendar account, when it already has a timezone set by the user?

When you say "it", do you mean the iCal feed, or the Google calendar account? If the latterm then I can just repeat what I said in #48:

When Google Calendar imports an iCal feed without TZIDs, it just shows time as is, i.e. UTC,

and I said it based on my actual experience, not any theory. If the former, then I do not have an iCal _feed_ with timezones set for events, but I have tried and imported an .ics _file_ with such events, and Google imports it keeping all timezones intact (and keeping UTC as UTC if the event being imported was set in UTC). I would expect the same for feeds.

This is clearly a complex issue—certainly creating iCal feeds with full VTIMEZONE records would be—so we don't want to add to the complexity with theoretical problems if they haven't actually been demonstrated to exist through testing. Just wondering if your New York coffee example might be one of those. :)

I do travel across timezones, and my New York coffee example is an example of things I do not use now with Drupal and Date iCal — precisely for the reason that it is impossible to use them in a convenient way.
I definitely understand that it may be difficult to implement all that timezone stuff, and I also understand that there may not necessarily be a lot of people who need it. I am just stating that _I_ would appreciate having it there. All in all, Duncan, I am not a Drupal (or any software) developer, and I have been using Drupal because it seems to be a great CMS for _my actual needs_. I would not spend time posting all sorts of theoretical "whatifs" here. Calendaring is one of those actual needs, and the lack of timezone export in Date iCal affects my ability to use Drupal with Date iCal to satisfy one of those needs.

and I said it based on my actual experience, not any theory. If the former, then I do not have an iCal _feed_ with timezones set for events, but I have tried and imported an .ics _file_ with such events, and Google imports it keeping all timezones intact. I would expect the same for feeds.

Interesting. Good testing. Perhaps you can explain a bit more what you mean here. Of course we want Google to keep the timezones intact, insofar as stripping the timezone information would render everything in an untagged "local" timezone regardless of your setting. So when you import an ics file with the dates encoded in UTC, it then changes your current Google calendar display so that you're no longer viewing your own calendar in your previously defined timezone, but rather you're now viewing a UTC timezone? That is an odd choice on Google's part. Personally, I have three timezones set as default available in my Google calendar, so it would be easy to just select the timezone I wanted again from the menu at the top right. But perhaps if you are not yet set up for multiple timezones it behaves differently. Hmm.

It also raises the question though, if that is what is happening—if you are currently set to Pacific time, and you import a calendar with the New York timezone set, does it then change your current display to be in the New York timezone? Because normally one wouldn't want that either.

I agree ics file vs. feed should be identical... it is just a delivery mechanism.

OK, I tested it. I had applied the patch in #42. Using my Google calendar set to UTC+12 (New Zealand) I subscribed to the calendar. I also was already subscribed to an identical calendar running on the live site which is still Drupal 6, and which was showing the times at the correct times. When it first loaded the events, they were indeed being displayed as though UTC was the current timezone, even though it wasn't—so they were showing as 12 hours ahead. I was mentally drafting my "Huh—you're right... I see it too" email when suddenly, about 10-15 seconds after it had started showing the events, they lept backwards 12 hours so they were now being displayed correctly in my local timezone, despite being provided in the feed as UTC. Which, after all, is what we would hope for and expect if this was working correctly.

So the two possibilities are that there is something different about our two calendar set-ups, or that in fact ical feeds and ics files are being treated differently by Google calendar for some reason.

Further test: I exported the same calendar as an ics file, rather than subscribing to it as a feed. In my Google calendar my other calendars are created as UTC+12 for New Zealand, but I created a new calendar and set the timezone of that calendar to UTC+10 for Sydney. I imported the ics file, which had dates expressed in UTC. The calendar appointments in UTC imported into the UTC+10 calendar then correctly displayed at the intended time when viewed in my calendar, which continued to show times in UTC+12. That is, the event originally entered on the website as 4pm–7pm on Friday in UTC+12 was shown at that correct time still, even though the ics file expressed the event in UTC, thus nominally 12 hours earlier if you read the raw times in the file.

At this point therefore I've not been able to reproduce what you're describing Maksym.

So my two thoughts are either that:
a) we're seeing an edge case here and there is something specific that your setup is hitting that mine isn't, or
b) what you're actually describing is that you want to be able to create events on your website as "4pm" and have that be imported into a New York-timezone calendar as 4pm, even though your website server timezone is set to some other timezone. That would be a reasonable interpretation of "Google imports it keeping all timezones intact". Are you saying you actually want timezone-independent events? (The iCal standard calls these floating date-times.) If so, that would be a feature request for a configuration option to switch the module to output floating date-times, not a bug in the current implementation—which with the patch in #42, appears to work as designed.

Sorry Duncan, I was not careful enough when testing, misleading you and others as a result. My most sincere apology here, and now I will explain in more detail what I thought I saw, and what actually happened :).
I saw that Google shows the timezone for an imported event having a TZID, and shows "UTC" for an imported event set in UTC (i.e. "....Z"). I _thought_ that it actually shows that event inn the respective TZID's local time (not my Google calendar's local time!). I.e., I _thought_ that if I have an event as , say, 4 PM to 5 PM Warsaw, Google actually shows it as "4 PM to 5 PM Warsaw". I did not realize that Google actually _does_ convert the time into the user calendar's timezone when rendering events.
I.e., the actual behavior is as follows. I created an ICS-file with several events within the same day: 16:00 to 17:00 Warsaw, 16:00 to 17:00 Kyiv, 16:00 to 17:00 Singapore, and 16:00 to 17:00 UTC. Upon importing into my Google calendar with its timezone set as Kyiv, Google shows them as 11:00 to 12:00 Singapore, 16:00 to 17:00 Kyiv, 19:00 to 20:00 UTC, and 23:00 to 00:00 New York, respectively.
I can make three conclusions here.
1. What I wanted to achieve was having those events shown in exactly the same form they were entered, i.e. as 16:00 to 17:00 Singapore, 16:00 to 17:00 Kyiv, 16:00 to 17:00 UTC, and 16:00 to 17:00 New York, — all in the same calendar. This was a totally unreasonable idea (actually even a stupid one, to be honest :)): since my Google calendar has its timezone, so it is reasonable to expect that Google will convert the time to that one.
2. Google seems to convert the time properly between all those timezones.
3. Still, the way Google _presents_ it does not look reasonable. It shows that "16:00 to 17:00 Singapore" event as 11:00 to 12:00 in my calendar (having Kyiv as its timezone), which is the proper timing for that event, but it says "11:00 to 12:00 Singapore", so one may think at first glance (before seeing that the calendar timezone is actually Kyiv!) that the event is to take place at _11:00 to 12:00 Singapore time_, which is definitely wrong :).

Sorry again for accidentally misleading you in my earlier messages.

Great to have this clarification.

3. Still, the way Google _presents_ it does not look reasonable. It shows that "16:00 to 17:00 Singapore" event as 11:00 to 12:00 in my calendar (having Kyiv as its timezone), which is the proper timing for that event, but it says "11:00 to 12:00 Singapore", so one may think at first glance (before seeing that the calendar timezone is actually Kyiv!) that the event is to take place at _11:00 to 12:00 Singapore time_, which is definitely wrong :).

I presume "Singapore" is the title of the event. I think that if the title of the event was something like "Teleconference with Singapre" or "Lunch in Singapore" then what is happening here might be clearer. If you were wanting to dial into the teleconference, which is happening at 11am Kiev time, then clearly it is being displayed at the right time... Alternatively, if on this day you are going to be present in Singapore, then a timezone-aware calendar will be set to Singapore time once you arrive there, at which point you will see in your calendar "Lunch in Singapore" listed at 4pm—and you will wonder, of course, why lunch is so late... :)

The key issue here sounds to me like it is how best to manage scheduling of appointments when you're currently in one timezone, but need to schedule appointments for when you'll be in another timezone. I have experienced this issue myself—it often feels like it would be easier to schedule them in a floating fashion (I'll just put lunch in at 12pm in *my* timezone, and then leave my calendar in my timezone even when I'm over there) but this rapidly tends to fall apart as you can end up with appointments that in a floating calendar appear to occur at the same time, as you have more than one occasion where you are experiencing "10am on Tuesday" in local time.

What's clear at this point is that this is an underlying issue in the *use* of timezone-based calendars, not a problem with the Date iCal module, and particularly with the UTC patch... Good that this has been worked through and clarified.

I presume "Singapore" is the title of the event.

Duncan, (sh)it happens, you are a genius (maybe), I am an idiot (definitely) :). To clearly see which event is which, I called them "UTC", "New York", etc., and forgot about it :). Indeed, what I saw in Google Calendar were event names, not timezones. Thank you again.
I must have spent too much time and energy working on my documents, discussing an upcoming assignment, etc. Not the best time to do any testing :). Thank you again!

Neither #20 nor #28 work for me - my iCal dates are all an hour late at the moment (but correct after the clocks go back next month).

This is still a major issue... has there been any further work or contributions since the last post?

I'm always reluctant to dig too deep into coding around the Date module and those connected with dates because I often get burned somewhere down the line... Time and dates involve such formidable caveats and calculations—kudos to all you who deal in fixing and making these modules.

same problem here! +1

Here's a temporary work-around that works for me today at:
webcal://www.nationalspacesymposium.org/agenda/feed (events starting April 7, 2013)

In the feed view, I saw a date-ical-vcalendar.tpl.php that could be used for my theme view template. I'm taking the rows and replacing the ending "Z" with "" like this, making the calendar look ok in a calendar app:

date-ical-vcalendar.tpl.php

/**
 * @file
 * Default theme implementation to display an iCal calendar.
 *
 * Available variables:
 * - $title: The name of the calendar.
 * - $rows: An array of events.
 *
 * If you are editing this file, remember that all output lines generated by it
 * must end with DOS-style \r\n line endings, and not Unix-style \n, in order to
 * be compliant with the iCal spec.
 *
 * @see http://tools.ietf.org/html/rfc5545#section-3.1
 * @see date-vevent.tpl.php
 * @see date-valarm.tpl.php
 *
 * @ingroup themeable
 */
if (empty($method)):
  $method = 'PUBLISH';
endif;
print "BEGIN:VCALENDAR\r\n";
print "VERSION:2.0\r\n";
print "METHOD:$method\r\n";
if (!empty($title)):
  print "X-WR-CALNAME;VALUE=TEXT:$title\r\n";
endif;
print "PRODID:-//Drupal iCal API//EN\r\n";
// Note that theme('date_vevent') already has the right line endings.
foreach($rows as $row):
  print str_replace("Z\r\n","\r\n", $row);
endforeach;
print "END:VCALENDAR\r\n";

Now the Cyber 1.3 Breakfast isn't at 1 a.m. anymore (no one wants to eat breakfast that early)!

The schedule/agenda feed can be compared with:
http://www.nationalspacesymposium.org/agenda

Right...who wants to review an epic patch?

Here's my thinking and my approach:

• Drupal's theme system is being used to assemble structured data, the iCal feed. You wouldn't use it to assemble a JSON object. We should use a library to create an iCal fed for us, rather than trying to do complex string manipulation to assemble a massively complicated file format.
• There is a such an iCal library for PHP, distributed under the LGPL: iCalcreator.
• I've re-written the views style plugin to use this library instead of Drupal's theme layer. The integration requires the Libraries module, version 2.0 or higher.
• I've re-implemented everything the current module does with the iCalcreator library, including repeating dates, but crucially time zone information goes into the created iCal feed.

Testing

To test this patch, you'll need to do the following:

1. Install and enable version 2.0 of the Libraries module.
2. Download the iCalcreator module from http://kigkonsult.se/downloads/index.php#icalcreator and extract to sites/all/libraries/iCalcreator, so that sites/all/libraries/iCalcreator/iCalcreator.class.php exists.
3. Apply the patch, and test away!

I would appreciate any feedback, especially from the module maintainer about this approach.

Here's some additional work, adding three alter hooks so that people can change the various pieces of the iCal feed without needing to override the views style plugin.

Actually this code now requires PHP 5.3 because the library does to compute all the timezones at the end, so declaring this in the info file.

@Steven Jones - I think, this issue queue isn't the right place to discuss implementing a third party library. This is a bigger module change/task which shouldn't fixed inside a bug fix. Please open a new task issue with your suggestion.

Sorry, I agree that adding the dependency on the third party library would be a huge change for this module, but as I mentioned in #33 there's just so much in the iCal spec that we should take advantage of libraries out there that implement that spec already instead of using the theme layer to do something it was never designed to do . IMHO this bug isn't ever going to get fully resolved without either integrating with a third party library or writing our own basically.

I will happily take this discussion elsewhere, and would love some steer from the module maintainers.

Opened a new issue for #1833362: Use a third party library for generating iCal feeds.

Back to needs work, so you can come up with other solutions for this issue. Sorry for the noise, but the only way this is going to work consistently is to start putting proper timezones into the feed.

#42 Appears to be working great for me.

#67 works well for me.

#42 works fine for me, too.

Also: I agree with Steven Jones that it makes totally sense to use a third party library here. Cred for writing the patch! But I agree with the conclusion in #1833362: Use a third party library for generating iCal feeds that incorporating this library should probably wait for a 7.x-2.0 branch.

The patch in #42 has been applied and committed to 7.x-1.x-dev, as part of #1686642: Combo Patch for 1460058, 1608738 and 1608836. This will be available in the dev build within a few hours, and the official 7.x-1.2 release some time this week.

However, I strongly suggest upgrading to the 7.x-2.x branch, since 7.x-1.x is in bug-fix only mode now, and will soon be abandoned. If you have any problems with the 7.x-2.x branch, please open a new issue.