I'm trying to map a date field in a source database to a CCK Date field in the destination Drupal database. The date field in the source database is a four-digit year (e.g. '1990'). What's the best way to map a four-digit year to a CCK Date field? Using the 'MigrateDateFieldHandler' class? If so, is there an example use of the MigrateDateFieldHandler class that I missed in the migrate_example module?

Comments

mikeryan’s picture

Status: Active » Postponed (maintainer needs more info)

Hmmm, we should really move the date field support to migrate_extras for consistency. But anyway, you shouldn't need to "use" the MigrateDateFieldHandler class, it should be invoked automatically when migrating to a field of type 'date', 'datestamp', and 'datetime'. What exactly happens when you just map the value to your date field? What value do you end up with?

tiyberius’s picture

Mike,

What exactly happens when you just map the value to your date field? What value do you end up with?

I start with '1991' in the source field and I end up with '1970-00-00T00:00:00' in the destination field ... coincidence that it's the beginning of Unix time?

tiyberius’s picture

Status: Postponed (maintainer needs more info) » Fixed

For anyone else having trouble, this problem can be remedied by defining a prepareRow() function at the end of your migration class. If you're not familiar with the prepareRow() function, it allows you to "manipulate the source row between retrieval from the database and the automatic applicaton of mappings". The four digit year that was in the source database was being misinterpreted by the strtotime() function in the MigrateDateFieldHandler class in the Migrate module. To remedy this, define a prepareRow() function at the end of your Migration class (to see a full fledged example, see line 450 of 'wine.inc' in the 'migrate_example' folder of version 6.x-2.0-rc2 of the Migrate module)

  public function prepareRow($current_row) {
    $source_id = $current_row->program_id;
    $result = db_select('legacy_program', 'program')
              ->fields('program', array('program_id', 'start_date', 'end_date'))
              ->condition('program_id', $source_id)
              ->execute();
    foreach ($result as $row) {
      if (!empty($row->start_date)) {
        $current_row->start_date = $row->start_date . '-01-02 00:00:00';
      }
      if (!empty($row->end_date)) {      
        $current_row->end_date   = $row->end_date   . '-01-02 00:00:00';
      }
    }
    // We could also have used this function to decide to skip a row, in cases
    // where that couldn't easy be done through the original query. Simply
    // return FALSE in such cases.
    return TRUE;
  }

As you can see, by appending '-01-02 00:00:00' to the four digit year ($row->start_date and $row->end_date), this can now be handled properly by the strtotime() function in the MigrateDateFieldHandler class of the Migrate module.

skitten’s picture

Where is MigrateDateFieldHandler? I have 7.x-2.x and don't see it anywhere, or in migrate_extras (which is presumably why my date migration isn't working…)

mikeryan’s picture

Date is a contrib module, so it should be supported in migrate_extras. Somehow, for D6 it never got moved to migrate_extras from Migrate, and it looks like it isn't supported at all in D7 at the moment, that should be a feature request for migrate_extras.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

drewish’s picture

This code didn't make it into the 6.x-2.0-rc1 release of migrate_extras but it's in the 6.x-2.x-dev release.

mnordstrom’s picture

What's the status with this issue? Relating to "looks like it isn't supported at all in D7 at the moment".

I have proper dates in the format 2011-12-12 00:00:00, which I try to map simply to a D7 Date field, and nothing appears in those. Also tried to convert them to UNIX timestamps before mapping, but with the same end result. What could be done?

EDIT: Installing Migrate extras helped, works now with both timestamps and that format (and probably lots of others).

ellenvdk’s picture

I also had a lot of problems with importing date with Migrate. At first, I always got the current date in the imported field.
Then I saw I still had an older version of the Date module. So I updated to Date 7.x-2.6, and then I got an empty field after importing.

The final solution was enabling the Date Migration module, that is part of the Date module!!
No need for Migrate Extras I think (at least for this date mirgration)

tinflute’s picture

The solution in #3 worked for me:
Appended '-01-02 00:00:00' to the end of year, in the prepare row.
Drupal 7 here.

daveparrish’s picture

I also had problems migrating the date until I read this guy's post.

I wasn't registering the Date Field Handler, so the migration wasn't doing anything for my date fields. To remedy this I needed to add the 'field handlers' section like this:

function my_migrate_migrate_api() {
  $api = array(
    'api' => 2,
    'field handlers' => array(
      'DateMigrateFieldHandler',
    ),
...
}

Perhaps Migrate could warn when a type doesn't have any registered file handler. I had no idea that I needed to do this, but perhaps I should have since field handlers are explained here.

geberele’s picture

Issue summary: View changes

Also make sure you have the right modules enabled and add them as dependencies in the .info file of your module.

dependencies[] = "date"
dependencies[] = "date_migrate"
dependencies[] = "migrate"