3

I have a migration that is successful except for the timezone. 

$this->addFieldMapping('dest_date', 'source_date');

For some reason the above code causes a timezone conversion to happen between the source date and the destination timezone. The migration seems to assume the source is in UTC and needs converted to Chicago time, giving me a result that's six hours later than it should be. The source date is in fact from the same timezone, so I want to avoid converting it. 

$this->addFieldMapping('dest_date', 'source_date')
  ->arguments(DateMigrateFieldHandler::arguments('America/Chicago', 'America/Chicago'));

The above code works perfectly, but when I run my migration I get this error:

The field mapping arguments() method is now deprecated - please use subfield notation instead.

However when I try to use subfield notation, I end up with the same problem again that I did when I had no arguments/subfields at all:

$this->addFieldMapping('dest_date', 'source_date');
$this->addFieldMapping('dest_date:timezone', 'source_date:timezone');

The above code doesn't seem to help at all, (edit: This is not surprising, as my field doesn't seem to have "timezone" as a subfield.) and the migration still seems to assume the source is in UTC and needs converted to Chicago time.

How do I convert my arguments to subfield notation without breaking them?

| improve this question | |
2

You can use it like:

$this->addFieldMapping('dest_date:timezone')
->defaultValue('America/Chicago');
| improve this answer | |
  • This works, but since 7.x-2.5 (?) Migrate has also supported ->addFieldMapping('dest_date', 'source_date')->arguments(array("timezone" => "...")). – J-P Nov 12 '14 at 14:32
2

I struggled with the same thing for hours before caving in and hacking the date module a teensy little bit :-)

My datefields are of the type "datetime" so I had to insert a timezone variable on line 158 of the date.migrate.inc file of the date module - like this:

        case 'datetime':
      // YYYY-MM-DD HH:MM:SS.
      $timezone = 'Europe/Copenhagen'; #add this line
      $from = format_date($from, 'custom', 'Y-m-d H:i:s', $timezone);
      if ($to) {
        $to = format_date($to, 'custom', 'Y-m-d H:i:s', $timezone);
      }
      break;

You can just remove it after migration. I would love a better solution - I thought of extending the DateMigrateFieldHandler class, but that just gave me double dates :-/

Hope this helps

| improve this answer | |
  • so I get why your solution would work and looks like a trivial hack, have an upvote. Although, I wonder if adding a pseudo-field in prepareRow to store the old value and then prepare and just setting the new date value to the old value (you're in the same timezone) ...... would be easier. I see posts like this and think people dont want to implement any of the Migration methods in their classes (and just try to everything via field Mappings). See: drupal.org/node/1132582 – tenken Jul 25 '14 at 14:58
  • again, I would love to fix this "the proper way", and I did try various methods using both preparerow and prepare to no avail. If there is some way to alter DateMigrateFieldHandler to use the correct timezone I have yet to find it. – Morten Jul 25 '14 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.