TimeZone wrong for UTC iCal data
| Project: | Feed Element Mapper |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Under certain circumstances, this module will not correctly map time zones.
Here is the use case which led me to this problem.
Time zone handling is set to site. The site's time zone is set to America/Los Angeles. The database time zone is set to UTC.
I am importing an iCal feed which contains times in UTC.
Here is what happens in feedapi_mapper_date.inc:
In feedapi_mapper_date_ical(), time zone is set to that used by the iCal feed: i.e. UTC.
However, in date_constructor-> build(), the fact that the times are in UTC is ignored. Instead, when the date object is created, it is set to whatever is the appropriate time zone for the site: in my case America/Los Angeles. This means that the created date object is incorrect by the difference between those time zones.
It may be that you would prefer to handle this in a different way, but I fixed it by replacing the following lines:
$this->value['date'] = date_create($this->start_datetime, timezone_open($this->to_tz));
$this->value['date2'] = date_create($this->end_datetime, timezone_open($this->to_tz));With the following lines:
// respect timezone setting
$this->value['date'] = date_create($this->start_datetime, timezone_open($this->timezone));
$this->value['date2'] = date_create($this->end_datetime, timezone_open($this->timezone));
// convert to site-appropriate timezone
date_timezone_set($this->value['date'], timezone_open($this->to_tz));
date_timezone_set($this->value['date2'], timezone_open($this->to_tz));At a minimum, a corresponding change is presumably needed for the date creation done by older versions of PHP.
Although I have a hard time seeing how it could cause a problem, since I have not looked at the other functions which use the date_constructor class, I can't claim that my patch is appropriate for general use.
#1
#2
Needs review. I'm not in the position to verify whether this is the right approach. Will ping KarenS on this.
Please roll mapper patches from the feedapi_mapper/ directory (not from feedapi_mapper/mappers/). Thank you!
#3
I will try to look at this over the weekend.
#4
Refering to http://drupal.org/node/474488
Given Google presents Ical with UTC dates, and I'm working on a Belgian site.
This patch works, but I can't fully comprehend the scope and as such if its the proper way to go.
However I do feel the need to repeat my thoughts:
Shouldn't the conversion happen as stated by the time zone handling of the date field used?
#5
After updating, the problem with the ical dates not being converted and being displayed in UTC persists.
Re-applying the patch works.
Will this one be commited?
#6
KoCo: Thank you for your feedback. This is valuable. I am basically waiting of getting a review from one of the date specialists (KarenS, wink, wink ; )
KoCo: You say that you're using a Google calendar feed, right? We should add a test to this patch against such Google calendar feed. This will help me in the future judge whether new patches are sane or not.
There is a lot of potential for regression in the date mapper and I am not a date module expert.
Setting this to 'needs work' until we have proper tests.
#7
I have been having the same problem: Google iCal feeds, non-recurring event times listed in feed as Zulu time not converting to site's timezone value.
I can also verify that applying the patch (manually) fixed the problem. The 2.x development stream of Feed Element Mapper also seems to posses the bug (if we're calling it that) as well.
#8
So far, so good. This patch fixed my calendar reading from a Google Calendar iCal feed. I'm in China so the timezone information is critical.
#9
I seem to be having this same problem (time zones coming in as UTC and being displayed as UTC instead of Los Angeles). Repeat events seem to work fine though.
I tried applying the patch but it failed:
patch -p0 < feedapi_mapper_date.inc451888.patch(Stripping trailing CRs from patch.)
patching file feedapi_mapper_date.inc
Hunk #1 FAILED at 275.
1 out of 1 hunk FAILED -- saving rejects to file feedapi_mapper_date.inc.rej
It might be that this patch is old compared to the version I am using.
Any advice would be appreciated.
#10
Try putting the patch manually with a text editor.
Alex_b: The google calendar feed I use is just the ical feed. I'll try to write all my adjustments to the parser, mapper, etc. down when the site goes into production. (I should have done so from the start, when will I ever learn ;-).
#11
Had the same problem...upgraded to 6.x-1.0, and applying patch fixes issue. I did, however, have to apply the patch manually as the line numbers had changed since patch was written.
#12
Had the same problem. Manually patching fixes issue. Thanks to all!
Before finding this thread/patch, my solution was to change the timezone setting for my datetime field (event content type) to UTC. Save content type. Refresh feed (times are still wrong at this time), set refresh option to 'never' & save feed. Change the timezone setting for my datetime field back to its original setting (Website's timezone). Reload calendar and Voilà!
All & all, a little convoluted, I admit. - Where there's a will there's a way - Lao Tseu :-)
#13
This patch also fixed my (some what different) problem.
- Google Calendar is GMT + 1
- Drupal site is GMT + 1
But with the ical feed import the timezone is always set to UTC.. ?? Maybe I did something wrong, but with this patch, the import of the time fields is done correctly.
Thanks.
#14
This patch is absolutely excellent. It solved an issue I've been struggling with since February related to importing iCal feeds from Google Calendar. I hope it is committed or the developers find another way to implement what this does.
#15
Hi All,
I ahve had similar issues with the timezone (reported elsewhere http://drupal.org/node/582148#comment-2119382 ). I have applied this patch which works, well sort of. For events up to the end of daylight savings (i.e. when the clocks go back) the times now appear correctly. However, after the clocks go back, times on events are 1 hour out. So, unless I am doing something wrong or have missed something, there still appears to be a bug here...
Nick
#16
@15: Not sure why that would happen. Three questions:
1) Are dates being stored in UTC? This is the norm/default. Are you doing anything to override it?
2) Is the value for $this->timezone correct?
3) Is the value for $this->to_tz correct?
My bet is that the answer to 2 and/or 3 is "no".
If that doesn't point to the problem, another question: is this problem occurring (a) only with events created before the clocks went back, (b) only with events created since the clocks went back, or (c) with all events? If (a), I'd wonder about #1 above. Otherwise, I'd guess that the problem is with #2 and/or #3.
Hope that helps.
#17
@16
1) Yes date stored as UTC and no as far as I am aware I am not doing anything to override it
2/3) where am I checking these values, which function?
All events were created in January of this year. The bit that confuses me, I have gone back and checked the source:
http://www.thatchamhistoricalsociety.org.uk/event/ical
When viewed on the site all dates and times appear fine. When downloaded to Windos Cal, the October ones are fine but November ones are 1 hour out. And google cal no longer loads it. So this is something to do with daylight savings/time zones. But I am not sure which module is at fault. It is looking, to me like it is not this module, but can someone confirm that please?
Nick
#18
@17 If the dates are all displaying correctly on the site, but not when you download from the site, that does not sound to me like this module. Although I might be wrong, so far as I know this module is only used for importing iCal feeds into Drupal. Since the problem you seem to be having is with exporting iCal feeds from Drupal, my bet is that the problem is somewhere else.
If you want to check the values I referred to, I believe the first post in this thread should help to find some good places to find those variables.
Hope that helps.
#19
@18, After much work and digging about I am still unsure what the problem is. However, ir is looking more and more like it is not this module creating the problem. Still not 100% sure though.
#20
Same issue with google calendar ical feed. All times were off by 8 hours (timezone GMT-8). This patch appears to fix the problem.
Thanks!