Wrong timezone handling in migrate process

This fixed my dates. The patch file doesn't work for me but, when patched manually, the dates started working correctly. Thanks!

I have the same issue, and after applying patch, it seems to work properly.
My only concern is that the migration process takes a date, converts it into timestamp using the given timezone, and then converts it back to date string using the given timezone. So as I see it, you can't actually change the timezone of a date field.

I use this patch in conjunction with #1888268: Date migrate generates undefined index 'timezone' notices.

In order to fix this properly we need to add support for timezones to the timestamp converter in the Migrate module. Ref. #2504517: Respect the timezone when converting a date to a timestamp.

In the meanwhile we can provide a patch that works around the limitation in the Migrate module.

@Placinta, from looking at the code your concern seems valid, the source timezone is applied again when the timestamp is converted back into a date. This should be the target timezone instead.

This patch solves the problem without having to wait for #2504517: Respect the timezone when converting a date to a timestamp to be accepted in the Migrate module first. I have added documentation referring to the upstream issue so this can be addressed once it is in.

I have also fixed the target timezone bug reported by @Placinta in #3.

Did some coding standards fixes in the code that was copied from Migrate, I see that an effort is done to maintain coding standards in the Date module, don't want to ruin that :)

I've been banging my head way too long trying to get the tests green. The patch from #6 was wrong, but in addition to that it appears that the two of the current tests are also wrong. When they were written the International Date Line was not considered. The tests use the "America/Los_Angeles" timezone which is UTC-8. If a timezone from across the International Date Line is used, like Asia/Tokyo (UTC+9), then the source date is one day in the future. See for example this conversion: 2011-11-18 06:00:00 in Tokyo, Los Angeles and UTC.

It appears that the output from the faulty logic was used as test data without verifying if the conversions were actually correct. Here are the wrong results:

Here is a better patch. What has changed:

1. Fixed the logic in DateMigrateFieldHandler::prepare(). This was not yet correct in the previous patch. Now the source and destination timezones are fully separated. The faulty logic where the timezone defaulted to 'UTC' when there was no timezone specified is now completely fixed.
2. In the meanwhile #2504517: Respect the timezone when converting a date to a timestamp has been accepted with some minor alterations. Backported this so that our version of ::timestamp() is exactly the same as the one used in the Migrate module. Let's still keep this in for a while until a new release is made of the Migrate module that contains the fix.
3. Added a test for importing UTC dates, to prove that this issue is fixed. I added a new field called field_datetime_utc for this.
4. Added documentation in date_migrate_example.xml explaining how to deal with different timezones.
5. Fixed the two faulty tests as described in the previous comment.

The "test-only" patch contains only the test. This should fail with a single error when importing the UTC time, to prove that the bug is real.

Tested patch #12 and it is working well.

Note that the user used to perform the migration will skew the timezone calculation.

The 3 year old patch in #12 to date_migrate still applies cleanly to the latest 7.x-2.x-dev. Would anyone else subscribed to this issue be willing to review/test this patch?

7.x-2.x-dev is gone, 7.x-2.11-beta2 is now the status quo now and the patch provided by @pfrenssen does not apply cleanly anymore, patching fails, so I've applied it manually and re-exported.

Implemented codesniffer_fixes.patch