Closed (fixed)
Project:
Drupal core
Version:
8.7.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
16 Sep 2018 at 09:40 UTC
Updated:
12 Sep 2023 at 10:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
claudiu.cristeaPatch.
Comment #3
claudiu.cristeaDammit, added also the composer.lock in the patch :)
Comment #4
claudiu.cristeaComment #7
mpdonadioThinking out loud here, but if the callable issue is limited to the migrations, can we add this as a helper class there instead of Component? Can the format_date migrate plugin be used?
Comment #8
claudiu.cristeaYeah, a component is too much. In fact the function has been used only by the RDF module (not only migration), so I propose that:
date_iso8601($timestamp)in favour of PHPdate('c', $timestamp)How about that?
Comment #9
claudiu.cristeaFixed the IS & CR.
Comment #10
andypostGood compromise
any reason to change signature?
Comment #11
claudiu.cristeaUnfortunately, the change of migrate source data should not have been done. The migration trick doesn't work. I have to investigate more.
Comment #12
quietone commentedCame across this and just noting that #2998666: Warnings after D7 upgrade caused by rdf migration has been committed which implements the most of the rdf changes in the patch in #8.
Comment #13
sjerdoComment #14
jcnventuraRe-roll of #8, after #2998666: Warnings after D7 upgrade caused by rdf migration.
No interdiff because it's way, way larger than the new patch.
Comment #16
jcnventuraAh well, that function is not actually testing date_iso8601(), but the callback mechanism. There's a timezone difference between using date_iso8601(), which seems to be using UTC+10, and CommonDataConverter::dateIso8601Value() which uses UTC.
Changing ISO date to also use UTC fixes the test, keeping it virtually the same as before.
Comment #17
jcnventuraComment #18
quietone commentedI read on d.o somewhere that the timezone for tests is Sydney/Australia which explains the UTC+10, but I can't find that page again.
Installed the patch and checked why the change to UTC. The change to UTC is necessary because CommonDataConverter assumes a format of UTC. I don't quite get why that is but then converting a time to UTC shouldn't be a problem. As stated in the issue where that was committed
Comment #19
catchCommitted e1c3458 and pushed to 8.7.x. Thanks!
Comment #22
quietone commentedpublish change record