On Windows the locale is set in the windows format which can not be parsed by the core_date::strftime that expects a unix-like format.

While completing the Moodle 4.1 release matrix, it has been detected that the recently introduced \core_date::strftime() is not working properly under Windows.

Link: https://gist.githubusercontent.com/stronk7/f2b22c8e36407e9acd4255a24132b3ff/raw/8c4efde044f2a66300aa1382a933420b9133b885/phpunit-win-postgres-4.1rc2

Errors like:

2) core\moodlelib_test::test_dst_changes

Failed asserting that two strings are identical.

--- Expected

+++ Actual

@@ @@

-'Sunday, 26 March 1989, 01:59'

+'domingo, 26 marzo 1989, 01:59'

C:\Users\stronk7\git_moodle\integration\lib\tests\moodlelib_test.php:1957

C:\Users\stronk7\git_moodle\integration\lib\phpunit\classes\advanced_testcase.php:80

phpvfscomposer://C:\Users\stronk7\git_moodle\integration\vendor\phpunit\phpunit\phpunit:97

Problem seems to be that the new Intl/ICU/CLR functions that we are using only understand the Unix (en_AU or en-AU) locales, but not the Windows ones (English_Australia). And the new function, when not locale has been specified, is running this:

$locale = setlocale()

That, under Windows, returns one of those not valid for Intl Windows locales.

Similarly, we cannot use moodle_getlocale() because it also returns a Windows locale.

Instead, we need to guarantee that the new method always use one of the Unix-like locales when not locale has been set. In fact, ideally, we should be able to map any Windows locale to its Unix locale counterpart, but that's surely too much for the time being (2 days before release).

Looking to other places already using Intl... like for example the core_collation class, it seems that simply getting the (unix) local from lang file is working ok, so maybe we should do the same here and forget.

Note that old strftime() function did work using the OS locales (it is a C lib), but the new one, PHP81 compatible, using Intl... as said, only knows ICU/CLR locales (unix-like).