I was seeing issues with date field values on a d6 to d7 migration. I have date migration enabled (7.x-2.6). I'm not sure if this is a d6 issue or a global problem with the destination.

When I just ran it as a simple field mapping with nothing else, I was loosing end dates and I was seeing timezone offset issues.

To compensate, I added code to my prepare method that copied value and value2 from the row. Here's what the final code looked like for me.

/**
 * Event node migration, which extends a custom parent class (which isn't doing anything with the dates)
 */
class ExampleNodeEventMigration extends ExampleNodeMigration {
  public function __construct(array $arguments) {
    parent::__construct($arguments);
    // Date mapping (see prepare below)
    $this->addFieldMapping('field_event_datetime', 'field_date');
  }

  /**
   * Make changes before we save the node
   */
  public function prepare($entity, $row) {
    parent::prepare($entity, $row);
    // Make adjustments to the date field if it exists
    // Otherwise, we loose the end date and the start date has an incorrect timezone adjustment.
    $lang = LANGUAGE_NONE;
    if (isset($entity->field_event_datetime[$lang])) {
      foreach($entity->field_event_datetime[$lang] as $delta => $date_info) {
        // Set the value
        $entity->field_event_datetime[$lang][$delta]['value'] = $row->field_date[$delta];
        // Try to set the end date
        if (isset($row->{'field_date:value2'}[$delta])) {       
          $entity->field_event_datetime[$lang][$delta]['value2'] = $row->{'field_date:value2'}[$delta];
        }
      }
    }
  }

}

With that quick fix, my end dates are back and everything comes in at the correct time. Note that I'm using a default timezone. Hopefully that helps others who run into this. Sorry I can't dig deeper to see where the actual issue is. Thanks!

Comments

Angry Dan’s picture

Angry Dan commented

I had a similar issue with timezone offsets. Here's what I did in my constructor:

    $this->addFieldMapping('field_date_published', 'field_date_published')
      ->arguments(array('timezone' => 'Europe/London'));

Using the timezone argument of the date_migrate module I was able to tell it what the source timezone was and therefore how much offset needs to be applied. Works perfectly.

Not sure about your end dates disappearing though - that's strange.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Postponed (maintainer needs more info)

What version of Migrate are you using? How were you mapping the end date? It should look something like this:

$this->addFieldMapping('field_event_datetime', 'field_date');
$this->addFieldMapping('field_event_datetime:to', 'field_date:value2');

The field handler on the destination side is looking for 'to' as the subfield containing the end date, but on the source side it's using the raw column name.

seanbfuller’s picture

seanbfuller commented

Thanks for the replies. Migrate is 7.x-2.4. Based on your feedback, I just tried this:

<?php
    $this->addFieldMapping('field_event_datetime', 'field_date')
      ->arguments(array('timezone' => 'America/Chicago'));
    $this->addFieldMapping('field_event_datetime:to', 'field_date:value2');
?>

The timezone argument fixed the start times, but I still didn't get end dates. It's very possible that there's an issue with my source database. Since my original method is working for me, I'm going to stick with that for this project. I'll leave this as needs more info and if someone else runs into similar issues perhaps they will find it. (Or just feel free to close it.)

The only other thing I'd suggest is documenting this (and probably other non-standard fields when using d2d). I'll create a new issue for that.

Thanks for the help.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Category: bug » support

Note that the arguments() method is deprecated, now that we have subfields. Here are mappings that work for me coming from a test D5 site:

    $this->addFieldMapping('field_my_date', 'field_test_date');
    $this->addFieldMapping('field_my_date:to', 'field_test_date:value2');
    $this->addFieldMapping('field_my_date:timezone', 'field_test_date:timezone');
shashikant_chauhan’s picture

shashikant_chauhan commented

I am using drupal 7.16, migrate and migrate_extra 7.x-2.5, Date Migration 7.x-2.6.
I am also trying to migrate date field from drupal 6.25 and my both DB are in MYSQL and column type is datetime.
I tried method #1 and #4 for date field migration but it is not getting migrated.

   $this->addFieldMapping('field_date', 'field_date_value')
      ->arguments(array('timezone' => 'America/New_York'));

    $this->addFieldMapping('field_date', 'field_date_value');
    $this->addFieldMapping('field_date:timezone', 'field_date_value:timezone');

Is there any working example for migrating field of type date, node/user reference, email . From Drupal 6 to drupal 7.
Or where can i get more help on migration for such fields.

dgtlmoon’s picture

dgtlmoon commented

hmm cant help but to think some working examples would save a lot of people some time, could be a documentation issue?

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Project: Drupal-to-Drupal data migration » Date

Comment #4 is a working example for me. Without more information, I can't tell why it wouldn't work for you - you need to do some debugging (seeing how the values get passed through prepare(), and through the data field handler).

Nothing here is specific to migrate_d2d - moving to the Date module.

joelstein’s picture

joelstein commented

Just so everyone knows, the subfields approach Mike uses in #4 above won't work until this patch is applied to Date: #1715700-6: Support for migrate v2.4 (subfields). Please weigh-in there to get it committed.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)

See #1715700: Support for migrate v2.4 (subfields) and #2034231: [META] Integrated patch for migration changes (apply the latter patch to fix most if not all of your date migration problems).

Erik_S’s picture

Erik_S commented

I am having a related issue with the Date fields, and as far as I can tell this issue is not fixed and persists.

I am running a migration into a *Date* field. I cannot seem to populate the database columns: field_data_event_offset and field_data_event_offset2 in the field_data_field_event_date table with migrations.

There appear to be no subfields to access these columns, despite being able to populate the field_event_date_timezone column. The absence of the offset fields causes the content to fail to display. A direct sql query that populates the column fixes the issue, but is undesirable.

Best,
Erik