Deprecate and migrate strftime formats

[herrvigg]

The strftime function is deprecated with PHP8.1.
We have now a substitution called qxtranxf_intl_strftime (based on IntlDateFormatter working with PHP8.1) - see #1228. This change is mostly transparent for the users, allowing to use PHP8.1 already now and keep in principle the current strftime or date tags as before (default or by language). There is an advanced option called "Date / Time Conversion" to select the format, but no need to change... yet. It is supposed to work for both. However, there are many caveats.

(A) The "strftime format" used in qTranslate has been extended to mimic some "date" formats.
For example: %q mimics date S for english day ordinal number (1st, 2nd, ...). That doesn't exist in strftime.
A full list can be found here: #1085 (comment). Most of these "extended tags" fill some empty gaps so it's acceptable, but a few ones are overriding existing official strftime tags. That's not good and those won't be supported anymore in their qTranslate definition. They look quite specific so it should not be a big problem.

date => strftime
'z' => '%F', // z: The day of the year (starting from 0) -- %F: Same as "%Y-%m-%d
'P' => '%s', // P: Difference to Greenwich time (GMT) with colon between hours and minutes -- %s: unix timestamp
'L' => '%k', // L: leap year -- %k: Hour in 24-hour format, single digit

(B) The "date" format is not handled natively by qTranslate.
It is converted to this "extended strftime format" and then goes through a strftime call... But there are also some calls to date to deal with the "extended format"... so it's a terrible mess. Moreover, the basic date function does not care about locales so there are surely some limitations.

So, I suggest to abandon the strftime formats completely because it's such a mess to maintain. Here's the plan:

1. support the date format natively, but we need to support it with the locales through IntlDateFormatter. It's different from the new strftime implementation, this doesn't exist yet.
2. deprecate the strftime values and migrate the strftime values to date. We need point 1 in place before doing this.
3. abandon strftime completely and remove all the legacy code

[herrvigg]

It's even more complicated than expected. IntlDateFormatter is not following the date format but it has its own...
https://unicode-org.github.io/icu/userguide/format_parse/datetime/#datetime-format-syntax

😓

[herrvigg]

With #1238 I have now generalized the usage of qtranxf_intl_strftime to any PHP version, not just PHP 8.1.
Merged in master, please test this so we can release it.

Eventually the strftime may disappear but this requires more work.

Also, I dislike the two QTX_DATE_OVERRIDE and QTX_STRFTIME_OVERRIDE settings.
The use case is very unclear : "replace formats with the predefined formats for each language".
It can be interpreted in different ways: (1) replace the user requested format with the language format or (2) replace the language format with predefined language format... I intended to not change the legacy behavior which is corresponding to (1) but that doesn't make any sense to me. I don't see who would like to use this. It's creating unnecessary complications so I will certainly deprecate and remove those.

[alphp]

There is a "replacement" written in php:
https://github.com/alphp/strftime

Original code: https://gist.github.com/bohwaz/42fc223031e2b2dd2585aab159a20f30

Original autor: BohwaZ

[herrvigg]

Yes, you already mentioned it in #1085. It's been merged in #1228 with a few modifications needed for qTranslate-XT.

However we should stop using strftime formats since it's not supported natively. We should keep only the date format that is used in WP or... something closer to the new IntlDateFormatter that is yet another format...

[TheWitness]

There is really no analog for strftime(). The PHP Group screwed up IMNSHO.