Closed (fixed)
Project:
Migrate
Version:
6.x-2.0-rc1
Component:
Documentation
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
10 Feb 2011 at 20:48 UTC
Updated:
18 Jul 2014 at 16:26 UTC
Jump to comment: Most recent
Comments
Comment #1
mikeryanHmmm, 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?
Comment #2
tiyberius commentedMike,
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?
Comment #3
tiyberius commentedFor 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)
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.
Comment #4
skitten commentedWhere 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…)
Comment #5
mikeryanDate 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.
Comment #7
drewish commentedThis 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.
Comment #8
mnordstrom commentedWhat'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).
Comment #9
ellenvdk commentedI 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)
Comment #10
tinflute commentedThe solution in #3 worked for me:
Appended '-01-02 00:00:00' to the end of year, in the prepare row.
Drupal 7 here.
Comment #11
daveparrish commentedI 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:
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.
Comment #12
geberele commentedAlso make sure you have the right modules enabled and add them as dependencies in the .info file of your module.