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?

2 Answers 2


You can use it like:

  • This works, but since 7.x-2.5 (?) Migrate has also supported ->addFieldMapping('dest_date', 'source_date')->arguments(array("timezone" => "...")).
    – J-P
    Commented Nov 12, 2014 at 14:32

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);

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

  • 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
    Commented Jul 25, 2014 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
    Commented Jul 25, 2014 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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