fix!: read timezone from config

[Dennis Garding (DennisGarding)]

closes: shopware/shopware#14186

This PR adds a source timezone premapping for Shopware migrations and uses it when converting date/time values.

The source timezone is read automatically only for Shopware API gateway connections. In that case, the Migration Connector endpoint returns the source system timezone, and we preselect it if it is a valid PHP timezone identifier.

For local gateway connections, the timezone is not read automatically. The premapping is still displayed so users can select or retain a timezone manually, but we do not call the API timezone reader for local connections. This avoids using the incorrect transport for local gateways and prevents crashes on connections that do not use the API connector.

If no valid source timezone can be detected, the migration retains the existing behavior unless the user explicitly configures a timezone in the premapping.

[Malte Janz (MalteJanz)]

The more I think about it, the more I think the extra effort for reading the SW5 configured timezone isn't worth it. Sorry for leading you down this EnvironmentReader path with my previous comment and our short talk.

What if we apply the simplest solution we could come up with here, just a few of my thoughts (feel free to explore a simpler approach on your own / deviate from this):

• No reading (or guessing) from the source system at all
• Premapping has a option for setting the "storage timezone" of the source system, which is like all other premappings put into the mapping table and can be used from there
• possible choices would be all valid timezones
• we could think about defaulting / pre-selecting "UTC", if that works for the majority of cases and otherwise the user can still adjust it and migrate again
• I still like your approach of using Converter->convertValue(..., TYPE_DATETIME) to do the correct conversion automatically, but I would prefer if we could get rid of the extra Context parameter there and initialize the internal used source timezone differently from the mapping

My reasoning behind this:

• Doing a full "read environment" call is expensive and should not really be necessary. I previously thought we might store the values of that somewhere in the DB but I was wrong about that (turns out we store it on the swag_migration_run but at the premapping stage we don't have a run yet)
• The other premapping readers also sometimes read from the source system, but they only use a dedicated $gateway->readTable API. In our case we don't need DB data but rather configuration values stored as a file. Introducing extra APIs for that seems not worth the effort
• Reading the SW5 config from a PHP file is error prone, e.g. they could also store the timezone in a variable and use that in multiple places 'timezone' => $timezone or other strange things
• (Not sure about this one) but is that config.php really the single source of truth for this configuration in SW5? Is it not possible to override / provide config values via environment variables or other ways, where this config.php value could be wrong / unused?
• The only reliable way I see would be asking the SW5 backend itself (e.g. they executed config.php and can tell what value is "active"), but that wouldn't work for our local gateway and doesn't seem worth the effort just for giving the user a little more convenience

[Malte Janz (MalteJanz)]

Because there aren't any comments / reactions to my previous comments (other than that they are resolved) and there is no meaningful PR description I have no clue what your current goal for a solution is. Looks like you still want to read the source system timezone?

Nevertheless the current implementation still has lots of issues related to that and also didn't follow my suggestion to not read from the source system to keep it simple. Please provide proper solutions to these issues or refactor to not read from the source system.

[Dennis Garding (DennisGarding)]

Because there aren't any comments / reactions to my previous comments (other than that they are resolved) and there is no meaningful PR description I have no clue what your current goal for a solution is. Looks like you still want to read the source system timezone?

Oh sorry, i forgot the PR descriptioin. 😅

We had agreed that once we’d dealt with a comment, it would be marked as resolved.

Nevertheless the current implementation still has lots of issues related to that and also didn't follow my suggestion to not read from the source system to keep it simple. Please provide proper solutions to these issues or refactor to not read from the source system.

I don’t see any (lots of issues related), and a suggestion is just that – a suggestion, not a specific instruction. If that were the case, the ticket would have needed to be drafted more thoroughly.

This solution is the best we can offer our users.