Add date formats support.

I think it should be a timestamp, for example: 1460968987

According to http://www.drupalcontrib.org/api/drupal/contributions!entity!includes!en..., values of type 'date' must be a round number:

case 'date':
case 'duration':
case 'integer':
  return is_numeric($data) && strpos($data, '.') === FALSE;

I think we should turn this into a feature request to accept also other formats besides a timestamp. We could take date_feeds_set_target() in feeds/mappers/date.inc as an example.

You can use feeds_tamper module to interpret the date string into a timestamp.

This patch adds support for importing dates using various date formats. Also added: timezone configuration on a date target.

Attempt to let the testbot also run the date test.

Try again on the testbot. I now have made a commit to declare date_api as a test dependency. Maybe that helps...

Reroll, which is needed because of the changes in #2891392-5: Coding standards, which added type hinting to getFormField() method.

Small coding standard fix in FeedsEntityProcessorDateTest.test.

I came from https://drupal.stackexchange.com/questions/239021/what-date-format-is-re...

Code looks great to have. I haven't tested but in mentioned Stack Exchange @nigel have tested it. Seems to work :0

+++ b/tests/resources/content_date.csv
@@ -0,0 +1,8 @@
\ No newline at end of file

Missing end of file

@clemens
Thanks for the code review. I think that the CSV file doesn't have an empty line at the end is fine as it represents a source file to import, not a PHP file used in the application.

I found one small issue with the patch in #12. When entering a date on the default values section on the processor settings page, it gets converted to a timestamp upon saving the setting. This makes that the original entered date is lost in the UI, which makes it harder for users to figure out what date the default value is.

New patch. Let's see if this still passes all the date tests, otherwise I may choose to live with the UX issue instead.

Committed #14.