Add migration plugin for Datetime_range field

Sending this to the migration system; they will be able to evaluate this better. I do know people have been using migrations with simple field mapping, though, and not full plugins. I'm happy with it living in the Drupal\datetime_range namespace, though, if we want to add this.

Few small comments. But this would be Needs Work for test coverage.

1. +++ b/src/Plugin/migrate/process/Datetime_range.php
   @@ -0,0 +1,38 @@
   +/**
   + * @file
   + * Contains \Drupal\geofield\Plugin\migrate\process\GeofieldLatLon.
   + */
   

   No need for a @file declaration for something that contains a single class.

2. +++ b/src/Plugin/migrate/process/Datetime_range.php
   @@ -0,0 +1,38 @@
   + * Process StartDate and EndDate return the value for the D8 Datetime_range field.
   + *
   

   Don't need to mention D8 here. May want to wordsmith this to match the other process plugins a little closer.

3. +++ b/src/Plugin/migrate/process/Datetime_range.php
   @@ -0,0 +1,38 @@
   +    list($StartDate, $EndDate) = $value;
   

   I am not 100% sure if we allow camel case in core yet (there is an issue, but I can't find it). But, if we do, then the first character should be lower case.

4. +++ b/src/Plugin/migrate/process/Datetime_range.php
   @@ -0,0 +1,38 @@
   +    return array(
   +      'value' => $StartDate,
   +      'end_value' => $EndDate
   +    );
   +  }
   

   Can use [] syntax here; it's new code. Also, the final element should have a tailing comma.

In my D7 migration, this line fails:

list($start_date, $end_date) = $value;

The $value variable has non-numerical indices ('value' and 'value2'), which does not work with list assignments.

Setting to Needs Review to test the patch in #9.

Addressing comments in #8 (re-write of #9).

Added Unit test.

Corrected test class name.

I don't think this is necessary. Closing as duplicate to #2820490: FormatDate process plugin

@heddn:
When I get that right, the #2820490: FormatDate process plugin is meant for formatting non-drupal sources for importing/migrating (CSV and so on), while I expected this patch to fix problems migrating datetime_range fields from older drupal versions to d8...
So is it really a duplicate ?
My specific challenge is to migrate a d6 site with CCK datetime fields (containing from-to-ranges) to d8 - so does the #2820490: FormatDate process plugin help for this? Or should I try to use this patch (#17)?

Thank you!

Re #20: See https://www.mtech-llc.com/blog/gerardo-hernandez/migrating-date-ranges-c... on how to migrate date range fields using CSV. The idea would be very similar when pulling from D6/D7.

The idea isn't that something doesn't need to be one for date_range, its that an additional process plugin isn't necessary.

For automatically migrating D7 date fields with the todate setting enabled: they result in data loss when using migrate_drupal today. #3095237: Migrate Drupal 7 date field "todate" value fixes that.