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.
Comment | File | Size | Author |
---|---|---|---|
#31 | feedapi_mapper_date.txt | 15.4 KB | greenmachine |
#1 | feedapi_mapper_date.inc451888.patch | 1.19 KB | Sid_M |
Comments
Comment #1
Sid_M CreditAttribution: Sid_M commentedComment #2
alex_b CreditAttribution: alex_b commentedNeeds 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!
Comment #3
KarenS CreditAttribution: KarenS commentedI will try to look at this over the weekend.
Comment #4
KoCo CreditAttribution: KoCo commentedRefering 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?
Comment #5
KoCo CreditAttribution: KoCo commentedAfter 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?
Comment #6
alex_b CreditAttribution: alex_b commentedKoCo: 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.
Comment #7
jakemonO CreditAttribution: jakemonO commentedI 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.
Comment #8
CheezItMan CreditAttribution: CheezItMan commentedSo 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.
Comment #9
jdblank CreditAttribution: jdblank commentedI 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:
It might be that this patch is old compared to the version I am using.
Any advice would be appreciated.
Comment #10
KoCo CreditAttribution: KoCo commentedTry 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 ;-).
Comment #11
michaeldhart CreditAttribution: michaeldhart commentedHad 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.
Comment #12
bisonbleu CreditAttribution: bisonbleu commentedHad 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 :-)
Comment #13
Robert Molenaar CreditAttribution: Robert Molenaar commentedThis 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.
Comment #14
eusebius CreditAttribution: eusebius commentedThis 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.
Comment #15
nickbits CreditAttribution: nickbits commentedHi 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
Comment #16
Sid_M CreditAttribution: Sid_M commented@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.
Comment #17
nickbits CreditAttribution: nickbits commented@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
Comment #18
Sid_M CreditAttribution: Sid_M commented@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.
Comment #19
nickbits CreditAttribution: nickbits commented@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.
Comment #20
Nathaniel CreditAttribution: Nathaniel commentedSame issue with google calendar ical feed. All times were off by 8 hours (timezone GMT-8). This patch appears to fix the problem.
Thanks!
Comment #21
donquixote CreditAttribution: donquixote commentedPatch fixed it for me.
When is this rtbc?
Comment #22
jjmackow CreditAttribution: jjmackow commentedThe patch also fixed the issue for me too. One thing worth noting is that the time zone settings within the content type that is used for the actual events or calender items needs to be set to the server's time zone.
My testing included an ical feed from google calendars, which stores times in Zulu time. My tests were only done during non-daylight savings time, however, I did verify dates that were imported that fall during DLS, (During April 2010) and they were correct.
Comment #23
Sid_M CreditAttribution: Sid_M commentedGiven all of the above comments, I'm going to suggest that this has been adequately tested, and should be committed.
Comment #24
neclimdulUm... was the move to FeedAPI Extensible Parser an accident? I don't see any relevance.
Comment #25
Sid_M CreditAttribution: Sid_M commentedLooks like it happened as a side effect of Feed Element Mapper disappearing from the list of projects. I'm guessing this is because its maintainers are trying to move everybody over to feeds. See http://developmentseed.org/blog/2009/nov/03/good-bye-feedapi-hello-feeds and http://drupal.org/project/feedapi_mapper
Comment #26
neclimdulThat would be unfortunate. I talked to Aaron Novak about continuing to maintain FeedAPI so I don't know why FeedAPI Mapper would be any different.
Comment #27
neclimdulComment #28
jaharmi CreditAttribution: jaharmi commentedIs there any further status on this being rolled into the module? I'm using iCal parser 6.x-1.1 downloaded this past weekend (April 10, 2010) and it still appears to have the same issue with event times being offset for standalone, non-repeating events imported via Feed API from a shared Google Calendar. I'm hesitant to patch the module (rather than use a released version of it) for a site I'm working on.
I tried using the 6.x-2.x version with Feeds but I was confused about how it worked, and all the tutorials that helped me get things set up for calendar views and "upcoming events" blocks are strongly geared towards Feed API. Therefore, I hope the issue can be fixed in both 1.x and 2.x, unless 2.x will work with Feed API as well as Feeds.
Comment #29
jaharmi CreditAttribution: jaharmi commentedFwiw, I applied the change from patch by hand to FeedAPI Mapper 6.x-1.3, in the feedapi_mapper/mappers/feedapi_mapper_date.inc file.
The change didn’t produce an immediate effect on my Event nodes, so I removed my feed items and refreshed from the feed. The change from the patch did present my future events with the correct time. I’ll double-check on some past standalone events.
HTH.
Comment #30
pianomansam CreditAttribution: pianomansam commentedConfirmed still to be an issue, with OP's patching seeming to resolve the problem.
Comment #31
greenmachine CreditAttribution: greenmachine commentedAlso confirmed that this is still an issue. Patch should be applied to the module. My version of feedapi_mapper_date.inc is attached (based on the 6.x-1.3 version of feedapi_mapper module) for those who just want a new file to replace the old feedapi_mapper_date.inc instead of trying to apply the patch. Just make sure to change the extension back to .inc
Comment #32
davepotts CreditAttribution: davepotts commentedIt's an issue for me too. I've had no luck with the patch, however.
My details:
Any ideas?
Comment #33
A Romka CreditAttribution: A Romka commentedawesome!
thank you for the patch!
Comment #34
lindsayo CreditAttribution: lindsayo commentedThe patch in Comment #1 worked for me. Wish it would get rolled into the module. Thank you, Sid_M!
Comment #35
Anonymous (not verified) CreditAttribution: Anonymous commentedHas this been rolled into the official release of the D6 version, or is the only workable solution to patch? Or, has work been suspended and the focus put on the successor of feed stuff, Feeds? I love Drupal, but there's got to be an easy (easier) way to import from Drupal and therefore keep control of the whole site in Drupal...
Anyone? Bueller? Bueller?
Comment #36
Caseinpoint CreditAttribution: Caseinpoint commentedSubscribed.
Worked on this for 3 days before finding this thread.
Is there any plan on the part of the Feed Element Mapper folks to update the code?
@greenmachine: Thanks for posting that file. It worked perfectly.
Comment #37
alexmc CreditAttribution: alexmc commented*sigh*
Seems to be the same problem here too. :-(
Will look into it locally to confirm...
Comment #38
jgknight CreditAttribution: jgknight commentedJust as a note to anyone using < PHP 5.2, this patch doesn't update the correct section. Near the end of the file, there's a line that checks for PHP_VERSION.
You'll have to copy what this patch does and paste it into that section of the if statement, otherwise if you're on anything less than php 5.2, the patch does nothing. I pulled my hair out for two days and finally figured this out. Hope it helps!
Comment #39
iva2k CreditAttribution: iva2k commented[EARLIER POST WITHDRAWN]
The patch only solves UTC problem for iCal records that have timezone set. All iCal records lacking timezone will still default to site's timezone.
Also, iCal is not the only input into datetime field that needs timezone fixing.
Comment #40
jgknight CreditAttribution: jgknight commentedIs this still being worked on? I appear to be having similar issues on my site still
Comment #41
jgknight CreditAttribution: jgknight commentedI've applied the fix, as it was not present in the lastest dev version.