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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sid_M’s picture

alex_b’s picture

Version: 6.x-1.0-beta9 » 6.x-1.x-dev
Status: Active » Needs review

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!

KarenS’s picture

I will try to look at this over the weekend.

KoCo’s picture

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?

KoCo’s picture

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?

alex_b’s picture

Status: Needs review » Needs work

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.

jakemonO’s picture

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.

CheezItMan’s picture

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.

jdblank’s picture

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.

KoCo’s picture

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 ;-).

michaeldhart’s picture

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.

bisonbleu’s picture

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 :-)

Robert Molenaar’s picture

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.

eusebius’s picture

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.

nickbits’s picture

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

Sid_M’s picture

@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.

nickbits’s picture

@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

Sid_M’s picture

@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.

nickbits’s picture

@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.

Nathaniel’s picture

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!

donquixote’s picture

Patch fixed it for me.
When is this rtbc?

jjmackow’s picture

Project: Feed Element Mapper » FeedAPI Extensible Parser
Version: 6.x-1.x-dev » 6.x-1.3

The 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.

Sid_M’s picture

Status: Needs work » Reviewed & tested by the community

Given all of the above comments, I'm going to suggest that this has been adequately tested, and should be committed.

neclimdul’s picture

Um... was the move to FeedAPI Extensible Parser an accident? I don't see any relevance.

Sid_M’s picture

Version: 6.x-1.3 » 6.x-1.x-dev

Looks 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

neclimdul’s picture

That 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.

neclimdul’s picture

Project: FeedAPI Extensible Parser » Feed Element Mapper
Version: 6.x-1.x-dev » 6.x-2.x-dev
jaharmi’s picture

Is 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.

jaharmi’s picture

Fwiw, 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.

pianomansam’s picture

Confirmed still to be an issue, with OP's patching seeming to resolve the problem.

greenmachine’s picture

FileSize
15.4 KB

Also 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

davepotts’s picture

It's an issue for me too. I've had no luck with the patch, however.

My details:

  • PHP 5.1.6 (using Date PHP4)
  • Date API 6.x-2.6
  • FeedAPI 6.x-1.9-beta1
  • FeedAPI Mapper 6.x-1.3
  • iCal parser 6.x-1.1

Any ideas?

A Romka’s picture

awesome!
thank you for the patch!

lindsayo’s picture

The patch in Comment #1 worked for me. Wish it would get rolled into the module. Thank you, Sid_M!

Anonymous’s picture

Has 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?

Caseinpoint’s picture

Subscribed.

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.

alexmc’s picture

*sigh*

Seems to be the same problem here too. :-(

Will look into it locally to confirm...

jgknight’s picture

Just 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!

iva2k’s picture

Status: Reviewed & tested by the community » Needs work

[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.

jgknight’s picture

Is this still being worked on? I appear to be having similar issues on my site still

jgknight’s picture

I've applied the fix, as it was not present in the lastest dev version.