Feeds Date mapper converts imported dates to GMT unless in UNIX timestamp format

This looks actually as expected. If you import a Tokyo time on your site, it will convert the time to GMT and then transpose it into the site's time zone whenever it is displayed. This is counterintuitive if you're thinking locally, for instance if you think about an event in Tokyo, but it is intuitive if you think globally, for instance a server shutdown in Tokyo that effects a global community.

Closed?

I don't know... I think the general use case for Feeds Importing with dates is to import dates into the site's local timezone, and the dates being imported would typically be preformatted to be the right time for a given site's time zone.

It's counter-intuitive to me to have to message my CSV files into GMT in order to get them to import (or set the date field to not use time zone conversion...).

Thinking globally, we could have a setting that says "convert times to GMT" and have it default to on, maybe, in the processor settings?

[Edit: Additionally, I can't even safely use the workaround mentioned in post #1, as apparently changing the time zone settings "could result in a loss of data" according to Date/CCK... I tested this and found that data is not lost, but is simply displayed differently with different TZ settings.]

Title change. (I'm in CST, so on my site 5 hours are subtracted from each date).

To get my import to work without too much hassle, I manually changed line 404 of FeedsParser.inc from:

      $db_tz = date_get_timezone_db($field['tz_handling'], $use_start->getTimezone()->getName());

to

      $db_tz = 'Etc/GMT-5'; // Change this value

If you are trying to do this to allow an import for your own site, you should be able to change the $db_tz value to whatever your local timezone's string is (as listed in PHP's List of Supported Timezones).

I'm running into this issue on another site now, and I'm trying to figure out what kind of string feeds requires so that the time zone of the incoming date is respected...

I have tried the following:

m/d/Y h:i:sa      -->  12/17/2010 10:52:14am
m/d/Y h:i:sa e    -->  12/17/2010 10:52:14am America/Chicago

But none of these seem to get Feeds to recognize the proper timezone of the incoming date.

I also did the following tests in Devel, just to make sure I was sane and strtotime() handled timezones correctly:

$no_tz = strtotime('12/17/2010 10:52:14am GMT');
dpm($no_tz); // returns '1292583134' for my site
dpm(date('m/d/Y h:i:sa e', $no_tz)); // returns '12/17/2010 04:52:14am America/Chicago' for my site

$tz = strtotime('12/17/2010 10:52:14am America/Chicago');
dpm($tz); // returns '1292604734' for my site
dpm(date('m/d/Y h:i:sa e', $tz)); // returns '12/17/2010 10:52:14am America/Chicago' for my site

No matter what string I send through Feeds, the GMT time is always returned... it seems that Feeds is ignoring any attached TZ information when creating date fields.

[Edit: It looks like the time zone ($tz variable) should work fine if sent to the 'FeedsDateTime' class (near line 455), so I don't think the problem is in that area of FeedsParser.inc.

I think something goes awry with the FeedsDateTimeElement class, causing it to not pass through the time zone value it receives from the feed data.]

Well, after all that... I converted the date start and end time fields (in the CSV source file) to timestamps ('U' is all that's required), and dates/times are importing correctly now. As a bonus, repeating events and all-day multi-day events are also working. Strange, to say the least, that timestamps work, while no other date string I used (with or without time zone on the end) would work.

I am also observing a counter-intuitive bevaiour regarding the timezones (I am setting node->created on import using the slightly modified patch from D7).
The time-strings imported look like this: 2010-12-29T19:52:44+0100

date_parse outputs them like this:

Array
(
    [year] => 2010
    [month] => 12
    [day] => 29
    [hour] => 19
    [minute] => 52
    [second] => 44
    [fraction] => 0
    [warning_count] => 0
    [warnings] => Array
        (
        )

    [error_count] => 0
    [errors] => Array
        (
        )

    [is_localtime] => 1
    [zone_type] => 1
    [zone] => -60
    [is_dst] =>
)

but setGranularityFromTime seems to overwrite the zone offset by UTC, resulting in wrong offsets.

I'm also experiencing this using feeds 6.x-1.0-beta10 but changing the format of the source dates is not an option for me.

subscribe

2011-05-25 14:00:00 becomes imported 2011-05-25 16:00
(cck date field with setting 'no time zone conversion', site in Europe/Amsterdam time)

maybe I do something wrong, but it feels not intuitive.

I changed my cck date field setting from 'no time conversion' to 'UTC' and the time fields show now correct! Also after reimporting.

Following this thread now from where I started in http://drupal.org/node/966846 - thanks Hanno.
Will try Unix format. I'm sourcing data from a user generated CSV file, so format should not be a an issues - as long as I can get one that works :)

@mudsurfer did the UTC-setting work for you?

@hanno, sorry, haven distracted by other projects, will test this in next 24hrs and report back.

Subscribe. Same problem.

@ZenLax can you try workaround #11 and see if it works for you?

I'm having the same issue with Feeds and Drupal 7.7.

EDIT: The same solution as #11 worked for me. I had to set the date field's time zone handling to 'UTC.' In order to do that, I had to first delete all nodes with that date field. (If you can't delete these nodes, you can create a new date field for this content type.)

Changing to UTC works but that of course changes the rest of the dates on my site's posted events. Looking at hacking FeedsParser.inc for now.

Hacking FeedsParser.inc didn't work either. Any other ideas?

I added an issue summary.

Since the maintainer does not agree that this is a bug (see Comment #2) I changed the category from "bug report" to "feature request."

I was able to get around it this way -- added the following to a custom module called "misc". Just uncomment the watchdog commands to introspect your date elements (mine were 'xpathparser:1' and 'xpathparser:2' for "to" and "from" timestamps) and change the importer id to your own (the importer ID can be seen in the URL, for example, when you edit the importer -- mine was at /admin/build/feeds/edit/brew_events) :

/*
 * Implementation of hook_feeds_after_parse().
 * We need to convert times to UNIX timestamps b/c of the following issue w/ Feeds module: http://drupal.org/node/722740 
*/

function misc_feeds_after_parse(FeedsImporter $importer, FeedsSource $source) {
  if ($importer->id == 'brew_events') {
    foreach ($source->batch->items as $item_key => &$item) {
      //watchdog('feeds', print_r($item,1));
      //watchdog('feeds', strtotime($item['xpathparser:1']));
      $item['xpathparser:1'] = strtotime($item['xpathparser:1']);
      $item['xpathparser:2'] = strtotime($item['xpathparser:2']);
    }
  }
}

added issue summary (see http://drupal.org/node/1155816)

It would be nice to get this fixed, because if all the imported items have timezone set to UTC, I have to change my default timezone to UTC as well, or calendar will display the items close to midnight on the wrong day. Also pathauto/token seem to think that the item's local time is +0300 if I don't have UTC as the default timezone.

If I stick to having default timezone as UTC instead of +0300, I'm sure it will bite me in the ass later at some other place.

I had success changing the date using the Feed Tamper module (http://www.drupal.org/project/feeds_tamper). Once installed, it gives you the option to apply plugins to the feed process that manipulate the data.

I was able to add the "string to Unix timestamp" plugin to my dates that were uploading as GMT, and they uploaded correctly. This was great, since we're going to have non-developer folks uploading data periodically, and asking them to manipulate the dates in a funky way would likely lead to disaster.

This module also helped with uploading taxonomy terms and getting the system to recognize them as individual terms instead of a string.

I added another work-around to the issue summary.

I dug into the /plugins/FeedsParser.inc where the FeedsParserDateTimeElement magic happens.

It seems around line 549 the $tz is always set to 'UTC', unless it was passed in as a parameter (which I don't see happening here). I made a patch to parse $time to get the timezone abbreviation to use to set the timezone. As long as $time is valid I think this should correctly set the timezone.

The block of code following seems irrelevant with my change but I left it in. I am not sure if my patch uses best practices with datetime strings, but it worked for me. Please test this patch and improve/review it!

Updated patch with minor improvement. Now uses the $tz if it was passed in as a parameter to constructor of FeedsDateTime.

Please test & review patch!

Anyone got a sample upload file with a bunch of dates to check for this?

Also, What's the rule we want to enforce with this anyway?
I'm assuming that the source, at a minimum, should specify a timezone. (if not, then assume UTC).
So during import, I see two choices, preserve the original timezone or convert to some other timezone (user/site) for presentation.
Is it more complicated than that?

I applied the patch feeds_parser_tz-722740-25.patch to my site and it fixed the issue I was having.

I have feeds 7.x-2.0-alpha4 and when I imported a date it would sometimes ignore the time and other times adjust the date/time incorrectly.

Site timezone is set to America/Los Angeles -0800
Field to import to is Date(iso format) - no time zone conversion
Importing via CSV
Format in CSV for date is 2012-9-11T18:30:00

After applying patch, the imported date was as expected, included the correct time and did not shift.

Thanks for the patch!

#25 worked for me -- greatly simplifies loading up a bunch of event nodes via a CSV file on my site. Thanks for the patch.

#25 works great on 6.x-1.0-beta11+9-dev --- Thanx!!

#25 works great on D7.19 and Feeds 7.x-2.0-alpha4 (as manual edited patch)

Thank you very much!!!

In my case, though, after applying the patch, the times are still shifted by 1-5 minutes, and I can't account for it. The data is "1/2/2012 00:00:00," but it shows up as 1/2/2012 :01" In some cases it's three minutes. Ideas?

Update: Sorry--this particular phenomenon was caused by an error in php date formatting. But the underlying issue of timezone, etc. were still happening.

@rsgracey does this effect also exist without this patch? Or is this patch causing it? If this patch is causing this issue, we should set the status to 'needs work', otherwise it's better to open a new issue.

I think, the error in #33 has another reason. I have tested it today again (importing events via CSV-file) with the current releases (as manual edited patch).
I get NO error.

I use D 7.12
Date 7.x-2.2+17-dev (2012-Mar-25)
Feeds 7.x-2.0-alpha4+40-dev (2012-Mar-01)

To avoid the errors in #1467830: Step-by-step instructions: Timezone-handling is wrong / editing and importing of date-fields are different, please patch the module with a patch like #25 soon (change line number).

Thank you very much.
Feeds is a great easy to use module.

Patch in #25 worked well for me. Thanks!
I spoke with @rsgracey re:#33 and this patch was not the cause of the issue he was experiencing.

I spoke too soon: #25 wasn't actually working for me.

strtotime() pays attention to the included time zone and translates the time, but since it only returns a Unix timestamp it's stripping the timezone data and not storing it in the imported date field.

So, instead of this (from #25:)

-    $time_arr = date_parse(date('D, j M Y G:i:s T', strtotime($time)));

The attached patch simply does this:

+    $time_arr = date_parse($time);

Because date_parse does parse and return timezone information.

And since that information could be in tz_id or tz_abbr format, this checks and uses whichever is included:

+    if (!isset($tz)) {
+      if (isset($time_arr['tz_abbr'])) {
+        $tz = new DateTimeZone($time_arr['tz_abbr']);
+      } elseif (isset($time_arr['tz_id'])) {
+        $tz = new DateTimeZone($time_arr['tz_id']);
+      }
+    }

This works for date fields whose time zone handling is set to "Date's Time Zone", where TZ is stored with the date. I'm not sure whether it'll work for other situations.

Patch in #37 (patched against dev release) fixed the issue for me. I have my Date field set to "Site's time zone handling" in the content type, and my sites time zone is CST.

Imported 300 + nodes with no issue and the dates and times are all spot on. Thank you!

This is a very important fix I've been waiting for some time. Let's have one more confirmation to get this committed.

I have continued to import hundreds of nodes under this patch, and my date fields continue to import flawlessly.

I ended up needing this, tested and it works fine.

To test this:

1 - Set your site timezone to some timezone different than GMT/UTC
2 - Create a content type. (Don't need to create a date field, as you can use the "Published Date")
3 - Create a Feeds importer with CSV parser
4 - Map 'date' to 'Published Date'
5 - Select the file attached, and run the import. Compare the node dates with the values in the file. I've set hours to be 00:00 so if you select a -x timezone it gets easier to see, as without the patch they get saved in the wrong date.

Who's birthday is August 18, 1985?

It was a random pick.

I tried this when using an End Date and, unfortunately, the imported timezone (if specified) is lost.

There are a number of different scenarios to verify here... we should add tests.

Drupal 7.14
Feeds 7.x-2.0-alpha4+47-dev (2012-May-12)

At the moment, an import of events like http://drupal.org/node/1477602 is wrong, if the "Time zone handling" of the date-field is set to "No time zone conversion". The timezone of the website is used instead.

Please help. Thanks...

Then I patch like http://drupal.org/node/722740#comment-5373838 ("#25" in this issue).
Now the time after feeds-import is ok.

Please patch Feeds with #25. Thank you very much.

Please patch Feeds with #25. Thank you very much.

It's #37. #25 doesn't work if you're including a timezone in your import data and set the field to "use date's timezone" or whatever it is.

Stephen

Does #37 also fixes #45?

Confirming #37 patch works for me, I'm not using a separate date field, just mapping to "Published Date". Thanks jeffschuler!

Although you have no problems, jeff himself states in #45 that his patch still doesn't work for all cases.

I'm quite sure this addresses none of the practical problems above, but should the patch at #37 have the timezone fall back to UTC if unable to find an explicit timezone?

subscribing

@Staratel
#56

Excuse my dumbness......
I will use the Follow button next time.

subscribing

@rvdtuinbeekman @sunnrunner There is more convinient way to subscribe : just use juicy "Follow" button at the top of this page. It helps avoid such unuseful messages, which worry everyone in the thread.

Thoughts:

• We shouldn't rely on the field settings when importing because they are used for display, is that correct?
• We could default the timezone to the sites timezone.
• A "Fallback timezone" setting *could* be added to the mapper now that the mapping config api is in. This has the drawback of not working for entity properties like node->created.

We need more tests for FeedsDateTimeElement and unit tests for FeedsDateTime to guarantee their behavior.

Am I missing anything?

The default of "Time zone handling" of the date-field should be "No time zone conversion". Then all is ok.

This is like the timezone on every airport (it is always local time there).

Thanks.

This is proving to be a VERY annoying bug.. Have been trying to work around it by adjusting my CSV files but got it wrong by an hour this morning and now have nearly 500 pieces of content each with 3 date fields that are all out.. Now I have to work out how to easily fix 1500 times..

Surely there is an easy way to get it to just take the time supplied and save it that way with no conversions at all, just save it to the database as supplied??

Anyway, I hope this can be resolved.. Looks like I am going to be here a while fixing times..

As a side note, I have used a very simple Feeds Tamper plugin to reduce amount of seconds from the source date. It works for this issue when I can't change the expected timezone, but is also useful if the source just happens to be in wrong timezone. Find the plugin attached.

I ran into this and it seemed to me like adding a setting was the best way to go. There is just too much ambiguity in trying to guess, and expecting people to include the timezone as part of the date strings themselves just doesn't work in many cases either.

So, the attached patch:

• Adds a configurable setting to each date target that allows the feeds configuration to specify the expected timezone of the data that is being imported (defaults to the site's timezone).
• #57 suggested this might not work for entity properties, but it looked to me like it was possible to add for $node->created and $user->created too (in addition to date fields), which I did. I've tested the $user->created one specifically (since I was using this to import users), and it seemed to work fine.
• Removes lots of code which tried to guess the timezone of date fields based on the field settings (which doesn't look like it ever worked anyway, and as #57 points out doesn't necessarily even make sense).

I'm also attaching a version of the patch which works with #857216: Behavior on importing empty/NULL/invalid dates (since we have that patch running too) but the main one to review is the second one.

Discovered this was unrelated. See:#1825682: Notice error correction
I am using the feeds module in conjuction with the Feeds_xpathparser. I am getting the following error:
Notice: Undefined index: unique in FeedsXPathParserBase->sourceForm() (line 172 of sites/all/modules/feeds_xpathparser/FeedsXPathParserBase.inc).

The import runs with only these warnings, but all the dates are in the wrong time zone.

Going to continue to look to locate the problem.

Patch from #61 applies cleanly on 7.x-2.0-alpha7 and with offsets for 7.x-2.x-dev and Timezone option show in Feed Mapping, but the time when imported is still off (in my case by 7 hours).

@arielqgold, I am working off of 7.x-2.0-alpha7 and I was able to apply the patch in #61 as well. This approach does look promising, but my dates are importing incorrectly (off by 2 hours, UTC to +0200).

The first issue I see with this approach is that any given import, or subsequent imports, might have date/times in different timezones. I'm guessing in most use cases that it is feasible to have the timezone data in the source, e.g. adding a column with the timezone data for the rows. Maybe not more casual users, but maybe there is a way to have both of best worlds.

I'll start looking around, but I'm thinking that instead of having the timezone selectable as a "Target Configuration" on the feeds importer target date field, to split the date field's timezone into a separate selectable target (like with Date: start and Date: end, and Title, URL, in the Link module).

By the way, the date/time field in my CSV file is in the (PHP) format: Y-m-d H:i:s O (e.g. 2012-12-04 12:02:35 +0800). I am thinking this is the better way to go than having the timezone offset in a separate field.

In the meantime, I am going to look into just importing the date and time parts into my date field (set to "Use Date's own timezone"), and then using VBO to set the fields to the correct timezone. My source does have a timezone specific field using the timezone abbreviations, like PDT, PST, CET, CEST, and I have been importing this into its own field on my nodes, so I could just filter on this field. I've been wracking my brain!

Back to the direct problem I am seeing with the patch in #61. My site's timezone is America/Los Angeles, which is -0800 right now. The PHP format of my date field in my CSV file is Y-m-d H:i:s O (e.g. 2012-12-04 12:02:35 +0800). The date field is set to Custom Format for the input, using the exact PHP string above.

• When the timezone for the "Target Configuration" of the date field target is set to UTC, and when my date field is set to "No timezone conversion", the dates import into the field but with the site's default timezone, 2012-04-17 18:06:19 +0200 turns into 2012-04-17 18:06:19 -0700.
• When the timezone for the "Target Configuration" of the date field target is set to UTC, and when my date field is set to "Date's timezone", the dates import into the field but with UTC as the timezone, 2012-04-17 18:06:19 +0200 turns into 2012-04-17 18:06:19 +0000.
• When the timezone for the "Target Configuration" of the date field target is set to UTC, and when my date field is set to "UTC", the dates import into the field but with UTC as the timezone, 2012-04-17 18:06:19 +0200 turns into 2012-04-17 18:06:19 +0000.
• When the timezone for the "Target Configuration" of the date field target is set to Europe/Berlin +0100 (the timezone of the source values of this particular import), and when my date field is set to "Date's timezone", the dates import into the field with the correct timezone (+0200), but get converted to two hours ahead 2012-04-17 18:06:19 +0200 turns into 2012-04-17 20:06:19 +0000.

Some good news is that it appears that the difference between daylight and standard time is respected, based on the date (?).

Tested Dec 4, 2012 7:02 PM MST
For the record this is what is currently happening. I have just started my research into this bug.

Goal: To send a unix timestamp from one site to another. Both sites are set to the same timezone.
Site A: Send the unix timestamp in this format: 1354932000 to 1354939200, which shows the start date and the end date in one field. I have checked, and that is indeed what is being sent.
Site B: Also formatted for a unix, also set for the same timezone, imputs the time as the current date and time.

Feeds Module: 7.x-2.0-alpha7

First, for the maintainers of this module, THANK YOU VERY MUCH. This is a complex challenge. My goal for sharing my thoughts is to help others with the same issue of sending time from one site to another.

As a programmer I want to know all the steps. For some reason the date being passed in is not being processed right on the receiving end. And there is always more than one way to skin a cat, so I want to see what is going on. To give other people a background, I have Site A - where the date value with end date is stored in a date UNIX field sent to Site B using Rules to create an email. Site B, using Feeds imports the date. But the date is not correct.

So here are my steps.

• Find out what the starting value is for the date field. I am using a unix date with the start/end date in one value.
  • My field name is event date unix.
  • The print array statement is: print_r($node->field_event_date_unix);
  • In my rules message I put the print statement, saved my content, which sends me an email. I now have the value that is being passed.
  • Checked the value, and the date is correct for MST, Mountain Standard Time.So the date being passed is correct
• Now, this is the interesting part. The unix field, when I go to http://www.unixtimestamp.org/, gives me two times, one for GMT time zone, which is what Site B is recording as the time, and the MST timezone, the correct date and time.
• I do realize that other people have reached the conclusion earlier, but I have to prove things to myself first.
• Keep in mind that I want the date in the timezone of my choice, for me is MST. Now that I have a value, I am going to play outside of Drupal. I created a small time script, using the time I received, set the default timezone in my code and use the date function, not the gmdate function.
  

  <?php  date_default_timezone_set('MST'); 
      echo date("M j, Y -  g:i ", '1354932000'); ?>

  . If I do not set the date_default_timezone, I get the GMT.

• Tomorrow I will figure out a way to add that date_default_timezone_set to the Feeds code and see if that solves the issue.
• Time is a complex issue, and since Drupal allows users to set their own time, the site to set time, and then I am sending data to another site, with possibly another configuration of time. The complexity of it is a bit much for late night thinking. Right now I need the project to work. So a one line 'hack' may be my temp. solution. I will write up the rest of my notes when I finish this section of my project.

For the record. I tried the Feeds Tamper module, sent the date as a string, set the Tamper Module to change the string to a unix time stamp. It did not work.

Here is my temporary work around. There are to many variables and considerations that the maintainers of this module understand that I do not. I am not offering a patch, I am saying that this is what has worked for me, to get me through this project. It is not a perfect solution in any way, but it does make my site useable.

I changed the unix date code into a 'string' and send that over to a text variable. Maybe tomorrow I will look at a way to convert it back to a time stamp. Please remember, I am not creating csv files, I am sending data from one Drupal installation to another.

I added this code to my rule:

<?php 
// Array of information for the field
date_default_timezone_set('MST');
$timestring = $node->field_event_date_unix[und][0][value];
?>
edateStart: <?php echo  $node->field_event_date_unix[und][0][value]."\n"; ?>
textdate: <?php echo  date("d-m-Y g:i a", $timestring); ?>

<?php 
//prints out the array 
//print_r($node->field_event_date_unix);
?>

On the receiving site, I created a text field and mapped the two together. It is a hack, but the site is now useable. Note, that I have left my edateStart variable in the mix so I can work on it. The values will not be shown until I am ready, but I do not wish to remove any structural items yet.

I tested it, and using Tamper (http://drupal.org/project/feeds_tamper)module, I converted the string back to a UNIX time stamp and it worked. I am going to stop my documentation here. I have not tested to see if I can pass a time range in etc. But I figure, if you are reading this you can figure that part out. I have a complex fix that works for me. I hope it helps someone else.

I have a rule which creates an email which is sent to sister sites. In the rule I have this code:

title: [node:title]
url: [node:url]
city: Name 
<?php 
// Array of information for the field
date_default_timezone_set('MST');
?>
textdate:<?php echo  date("Y/m/d H:i:s", $node->field_event_date_unix[und][0][value])."\n"; ?>
<?php 
//print_r($node->field_event_date_unix);
?>

Then in the sister site I have Feeds Tamper and I have modified the strtotime.inc function to this

function feeds_tamper_strtotime_callback($result, $item_key, $element_key, &$field, $settings) {
 // $field = strtotime($field);
 // date_default_timezone_set('MST');
  $datetime = DateTime::createFromFormat( 'Y/m/d H:i:s', $field, new DateTimeZone('America/Denver'));
  $field = $datetime->getTimestamp();
}

Still on the sister site in Feeds I set the textdate to map to the date field. And now I have the date. Finally. When I get time I will work on making a plugin for the Feeds Tamper module. It looks quite interesting.

Patch from comment #61 works for my use case, however it throws a Strict warning because the setTargetElement is not compatible with the parent.
Also in combination with the feeds_xpathparser it gives notices in that 'unique' is not defined in the mapping? So I added Unique as a form element... might be handy.

New patch on 7.x-2.x-dev.

Forgot the Strict warning for the UserProcessor.

I applied the patch on #70, the timezones are now working ok. But after appliying this patch, I was experiencing Entity Malformed errors (#1970460: Empty columns of CSV creates empty terms. Reverting the module, that problem disappeared. So I used the workaround with Feeds Tamper on comment #23.

The solution in #23 to use the Feeds Tamper module worked for me when importing an excel spreadsheet.

Using Feeds tamper -
Plugin: String to Unix timestamp

worked for me.

Thanks.

For testing...

#69: feeds-timezones-722740-69.patch queued for re-testing.

#11 worked for me.

I added a suggestion from #23 to the list of work-arounds in the issue summary.

Rerolling #37 against alpha8

Fix failing test - handle case when time doesn't set a timezone

So, I'm having the same issue. Here's the date format I'm trying to import: 2014-02-26 14:00 -0500. I tried the patch in #80, but it keeps changing every date to UTC instead of "America/New York". I have my date field set to "Date's time zone" cause the editors want to be able to assign a timezone to a particular event. Is my date format not right, or am I missing something? I tried using Feeds Tamper to change it to Unix, but that didn't work either, but perhaps I have the wrong format for the date. Any help would be really appreciated. Perhaps I should be using the dev version of the module?

The patch listed in #80 worked for me.

Anyone want to give this a shot? It's pretty thorough as far as what it will search for.

It also addresses setting the default timezone to the system default in all cases.

In the input I have a string "2014-08-07T19:00:00+02:00", then I map it to the field on site configured on Europe/Prague timezone (+2h, with daylight saving time).

Dev version of Feeds saves it as 1407438000 (= 2014-08-07T21:00:00+0200)

After installing patch #83 it saved 1407427200 (= 2014-08-07T18:00:00+0200)

Btw, I installed back dev version (without patch) used Feeds Tamper's "String to Unix timestamp" plugin and time is correctly saved, so it seems that something in Feeds' ISO-to-timestamp code is broken.

Quick test to see something.

I can add another dimension to this issue. Here is the scenario:

• - One importer uses the standard feeds common syndication parser (RSS) and imports into an event content type which has a date field for event date. The date field is configured to not do any time zone conversion (which is one of the proposed solutions in this issue). The imported content shows the time correctly. An event from this feed with date/time Wed, 03 Sep 2014 13:00 PDT imports on that day at 1pm.
• - A second importer uses XPath parser to import other events from an XML feed into the same content type. The date field is exactly the same as in the RSS feed (Wed, 03 Sep 2014 13:00 PDT) and the XML feed delivers it in the same format. However, the imported events show a date with a different time (the difference is time zone from feed to GMT, in this case -700), i.e. an event from this feed with date/time Wed, 03 Sep 2014 13:00 PDT imports on that day at 6am. If I change the date field to UTC, these dates come in correctly, but the ones from the RSS feed importer don't.

Either way, I am unable to get both importers to correctly import into the same content type and field. I will try to add Feeds Tamper module next to modify one of the importers.

However, what this tells us is that different parsers handle time zone conversion differently instead of one consistent approach in feeds. I would have expected either both importers to work correctly or import with the same wrong offset. I love the feeds module and hope that this issue can be fixed soon. Several potential solutions have been presented. The original issue was related to a CSV file which we might be able to change (option 4: adjust time in CSV file). I think for a long-term solution we cannot rely on the fact that the owner of the site controls what time appears in the feed/file. Any external RSS or XML feed cannot be modified like that. Given the problem I ran into with different feeds/parsers going into the same content type and entity date field, the solutions to set either "no time zone conversion" or "UTC" on the field level won't work consistently either.

It seems to me that we need a configuration option that is feed specific and allows us to specify what date/time will be delivered by the source and how we want to handle it so that the parser can transform it into whatever it needs...

I got this error from #86

DateTime::__construct() expects parameter 2 to be DateTimeZone, null given

#23 worked for me very well.

Patch #86 seems to be working for me. I’m using D7.36, Feeds 7.x-2.0-alpha8+84-dev, views 7.x-3.10, date 7.x-2.9-beta2+9-dev, MySQL 5.5.42-cll, PHP 5.3.29

The problem I faced before patching with #86 was this (simplifying data for clarity) …

- I have a date field in an entity.
- Set it to “no time zone conversion”
- I import a csv with “2015-02-12T14:30:00” raw
- However, time would store in the database plus 5 … “2015-02-12T09:30:00”
- Then in my View, that field would show “2015-02-12T09:30:00” when Formatter set to “date and time” but show “2015-02-12T14:30:00” when Formatter set to “Plain”. But then I got an even crazier result when I created a new View Page using that field. The same field showed two different times on two different View Pages.
- I tried a bunch of combinations of adding time zone “-5” to the CSV and all the importer settings no conversion, date’s time zone, UTC, etc. Could not get consistency between the DB, View’s Formatter “plain” and View’s Formatter “Date and Time”.

- So out of frustration I found and tried patch #86. Now all the combinations work, and the headaches are gone. Everything matches just like expected … the DB, the View’s Formatter “Date and Time”, the View’s Formatter “Plain”, the Entity View.
- I’m just starting to use this so may have some updates as I complete the development.

Thanks Twistor for ALL your great modules and this patch.

Reroll of #86

Here's an update to the patch to fix tests - failed due to PHP thing: https://bugs.php.net/bug.php?id=45543.

Updated patch - this fixed tests locally, let test bot decide!

Found two occurrences where ::setTimezone() was receiving a string - didn't get caught locally - around $db_tz.

So this is a PHP bug when dates are initiate with a certain timezone format and then set again with another (like UTC or 0:00). Here's the bug filing: https://bugs.php.net/bug.php?id=45543. Apparently it's only fixed in PHP 5.4.26 and 5.5.1 per http://3v4l.org/mlZX7

Sorry for test spam.

Ok, one more before I give up. This does a check to try and prevent resetting the timezone multiple times if it is set and equals the same thing. Green locally. Crossing fingers!

+++ b/plugins/FeedsParser.inc
@@ -616,16 +616,9 @@ class FeedsDateTime extends DateTime {
-    parent::__construct($time);
-    $tz = $tz ? $tz : new DateTimeZone("UTC");
-    $this->setTimeZone($tz);
+    parent::__construct($time, $tz);

PHP 5.3.3 has a goofy bug where passing null for DateTimeZone doesn't actually work as expected - see: https://bugs.php.net/bug.php?id=52063&edit=2

Patch which puts this back.

Thank you for the patch! Found the same problem, applied patch, tested. Worked for me.

I applied patch #102 and tried importing the date 8/31/15 8:00 and it came in as 8/31/15 1:00.

(my site is set to use pacific standard time).

Let's try a different approach. FeedsDateTimeElement is nonsense.

This is looking promising, sure could use some testing for people that are having troubles with this.

This needs some more testing.

Looks nice, suppose should work

Simple re-roll.

Yay enhanced test coverage!

Deprecating the old classes, making validation slightly more strict.

#120 works perfectly for me. Thank you!

Fix feeds_to_unixtime() to not rely on FeedsDateTimeElement.

Hi,

I am using version feeds version 7.x-2.0-beta1

Issue 1
When i import a csv file the date is always +2 hours. (in my own content type i use a date with no timezone conversion)

Issue 2
The date in the CSV file is like MM/DD/YYYY HH:MI => 08/15/2015 15:00 => 15 of august 2015
When i do not use this format the date stays empty in my own content type.

I am from belgium and normally we use DD/MM/YYYY HH:MI

Are there some settings wrong in my CORE?

@dvennens:
Look on https://www.drupal.org/node/1477602 for Step 1 at No. 4.
It may be, that this can help you, but I don't know.

Good luck!

In my so far limited testing the patch in #122 is resolving the issue. However because it changes the signature of date_feeds_set_target() it is incompatible with modules like feeds_xls that depend on this. In my case adding an empty array to the call to date_feeds_set_target() worked which makes me think perhaps for compatibility $mapping should be given a default of an empty array?

Hi,

patch in #122 works great against the dev version !

#122 works well for the one quick test I've done so far.

@twistor:

It also addresses setting the default timezone to the system default in all cases.

While this is a very sensible option, it does change the current default behaviour, which is to assume UTC if no timezone is specified. I suspect there may be a few out there who have their own timezone handling code based on this being UTC.

Because this setting is very obvious it could possibly default to UTC, with the next option being the site's timezone.

I'm not sure it's a showstopper, the change could just be documented and announced on the project page.

Can we get this one in, and then deal with follow-up issues in other tickets?

Thanks for the patch in #122. Worked like a charm.

This issue seems to have resurfaced with 7.x-2.0-beta2 and the patch #122 doesn't work with the new version.

#23 worked for me.

#131 worked perfectly for me on 7.x-2.0-beta2 -- looks like there are just some translation-y issues with the patch, if I'm correctly understanding the test results?

In any case, #131 solved all my problems, so thanks, @lapek and @twistor!

I'd suggest to use the patch from #5 in #2572581: Feeds ignore timezone-information for imported dates. It's much simpler and fixes the problem cleanly. We should close this long discussion, set this issue duplicate and commit the fix finally :)

@Anybody, that's not going to happen. This issue fixes a number of other bugs, as well.

I'm going to get this in today.

Two changes here.

1. Added back field translation support.
2. Changed the default timezone to UTC. (To avoid bc breaks)

Thanks all!

Please do not re-open this issue. If you have a problem, create a followup issue.