Localized date formats are initialized too late

Double-checked the bootstrap phases and function invocation order and this looks correct to me.

I suspect there's a PHP error or something, because "Parsed page successfully." appears often in the failing test results.

I don't see why not. The change is required to ensure that date formats are initialized before they are potentially used.

subscribing

#2: localized_dates-939392-1.patch queued for re-testing.

Why has this stalled? Also this is a major?

So, I've reviewed this and have pretty much worked out what the issues are, but I don't know of any good fix.

There are two separate dependency issues.
* This is the main one: locale_get_localized_date_format uses functions from the system module, but with this change the locale date initialization runs before the system module is loaded. This is also not that simple because these system modules could also trigger hooks, but at this stage the modules implementing the hooks aren't included yet.
* Also, tons of locale things assume that locale.inc has been loaded, but this patch makes it only load when drupal_multilingual() == TRUE.

I'm attaching the original patch again to get updates test errors, and a new patch that loads locale.inc in hook_init, so at least it's clear what things are failing because of the missing system functions.

So, I'm not sure this can be fixed with this approach...

Thoughts?

Should we just make sure that it is well documented that you shouldn't use format_date and other locale date functionality before hook_init, and maybe adjust hook weighting so that at least format_date can be used safely in hook_init?

I think / hope that this will not eventually apply to Drupal 8, since we are moving language to a context system and configuration to the CMI system, which will entirely change the storage and use of the date formats, initializing the language on demand when needed, so it will happen early enough. We are not there yet, so not sure we should downgrade this bug to Drupal 7 at this point yet :|

I wouldn't want to see this bumped down to 7.x until at least after the context system is in core and there's an active issue open for the language handler.

At that point we're wasting work in this issue on a D8 patch, but until that point anything could happen and the bug is still in 8.x.

Yeah, well, it would be wasted work either way. To the point when we figure out we'll not have the context/config systems or to the point when we get to have them. Until then, this major issue is just of those nobody should work on and will just count to the blocker list anyway.

Why is it not worth working on for backport to D7?

Yes, its worth working on for D7, that is why it would make sense to move it to D7 eventually :)

I'm downgrading this from major, there's no functional bug here, just the possibility that a module tries to access the date formats in hook_init() and we don't know of any (seems an odd place to access them too).

Also I'm not sure what the status is with this. The language globals have moved/are moving to the dependency injection container, but the way to dynamically override configuration at the moment is still to override $GLOBALS['conf'].

So, since localized date formats are now part of the configuration this one should be fixed for D8, moved to D7 queue, right?

Related, still a few issues with localized date formats #2052193: [META] Date format localisation is a huge mess, conflicts, does not work, regressed