DateTime support in FeedsDateTime

#1:

When you add an new date-field to a node, the default range of the field is -3 years to +3 years from the actual date.
When an field of the Feeds-imported CSV-file is empty, then Feeds sets the field of the node to now.
I think, this may be your problem, if the CSV-field is out of range, then it could be set to now, too.

What is the range of the date-field, you want to Feeds-import to?

I hope, this can help you.
Please tell us your experience.

Sub.

@AniaMi:
Please tell us your experience.

Same issue for me. Using this alpha4 version and latest 7.x-2.x-dev still have this problem.
I have CCK Date field, using custom input format (d/m/Y H:i:s), and in csv file using that format too.
Here is my sample row content of my csv file:

DVRU1530034 ;SANTA BHAITA ;145 ; 21.30;18/01/2008 06:41:12

After execute 'import', CCD Date field filled by node published date. Any solutions ?

#5:

What is the range of the date-field, you want to Feeds-import to?

Hey,

I'm experiencing this issue. I'd like to be able to go -10 +10. Is there an option to do that?

I have the same problem. Spend about two hours on it but could not find a solution. I want to import dates of last month so they can not be out of range.

Does anyone have any suggestions?

I searched for other import (more precise: update modules) but found none. Some pointing to Feeds. Hope the maintainers will pick this up.

Well, you could try the Feeds tamper module: it has a datetotime php conversion plugin:

String to Unix timestamp: Take a string containing an English date format and convert it into a Unix Timestamp. See the PHP Manual on strtotime for examples of valid strings.

PS: Good to know: when Feeds doesn't have a correct date, it currently defaults to now. See #857216: Behavior on importing empty/NULL/invalid dates

Thanks for the idea Hanno. But the Feeds tamper module did not solve the problem.

But your answer led me to examine the date format of the source. It was dd/mm/yyy (19/11/2011 for the 19th of november 2011).
I changed the format to dd-mm-yy. And now the records are shown as expected.

So thanks a lot for your answer!!!

Good to hear that you found a solution.
dd/mm/yyyy is indeed not understood in php in the strtotime function, as it is always interpreted as the American date format mm/dd/yyyy, and that will result in a invalid date (http://solidgone.org/PHP-strtotime-assumptions-with-European-and-America...).

Also note that strtotime only understands months and relative dates like 'yesterday' when it is written in English. These are all the valid input formats:
http://www.php.net/manual/en/datetime.formats.date.php
http://www.php.net/manual/en/datetime.formats.relative.php

Hey All,

I also found a solution. I just changed the dates to UNIX format and it worked. If you're using Excel, here is a quick formula: =(CELL * 86400) - 2209075200

I hope this helps you all!

Anyone experienced a problem where dates pre-2000 import fine, but post-2000 set to current year? I have a column where the only info is a four digit year. With and without a feeds tamper to convert string to unix timestamp, all the post-2000 dates import as current year, while earlier years get added correctly.

The root of this issue is that class FeedsDateTime() sends all its input through strtotime().

strtotime (32 bit) simply does not handle the range of dates afforded by PHP's DateTime extension (64 bit).

The comment around the call to strtotime is

// Some PHP 5.2 version's DateTime class chokes on invalid dates.

however, I don't think that's a good rationale for hobbling this field handler for other PHP versions, especially since Drupal's recommended version is 5.3

Attached patch adds a conditional based on PHP version, and provides full DateTime support for PHP 5.3+

I've posted a patch (and some test coverage) here https://www.drupal.org/node/1058424 to solve the same problem (strtotime used on all dates).
The patch uses date_create instead of strotime to allow dates before 1902 to work.

#1058424: Port date mapper patch to d7 version to support dates before 13 Dec 1901

This looks like it was fixed in the issue above.