Undeprecate strftime() because the rationale for deprecating it doesn't make sense

[mikkorantalainen]

Description

The function strftime() is deprecated because it's not thread safe because setlocale() is not thread safe.

However, the function sprintf() is similarly dependant on current locale and it's not deprecated!

I think it would be much better idea to move locale settings to thread specific data area and keep allowing use of strftime() and sprintf() without weird edge cases in case of threaded (as opposed to process based) web server. This solution is already used for thread-safe gettext variants so it should work in practice.

I repeat, the problem is not that strftime() or sprintf() wouldn't be thread safe; the problem is that setlocale() is not thread safe.

It would make more sense to deprecate setlocale() if you don't want to change its semantics to change only the locale of the current thread. And then introduce another function with thread specific semantics to set locale.

Note that you already have created non-standard behavior because Windows variant of PHP already has thread-specific locale as of PHP 7.0.5: https://www.php.net/setlocale – it would make more sense to standardize this behavior for all platforms because it would make PHP behave the same on all platforms and fix the non-thread-safe behavior of sprintf() and strftime() without deprecating anything.

[DeveloperRob]

From reading the RFC, it seems that the primary reason was around differing support (or behaviour) depending on the platform (as explained further in the red box on the manual page), While having locale per-thread might make sense, it wouldn't solve (all) the problems with the function.

[Girgias]

Like @DeveloperRob said the reason for deprecating it has nothing to do with the locale.

Moreover, this got accepted by an RFC vote, and the only way to reverse this decision is by going through another RFC, if you intend on pursuing this please email the internals mailing list to request Wiki Karma and follow the usual RFC process.

[mikkorantalainen]

3rd parties sure seem to believe that the strftime() is deprecated because of locale dependecy. At minimum, the communication to the developers has failed so documentation should be more clear about this kind of decisions in the future.

Example case: https://php.watch/versions/8.1/strftime-gmstrftime-deprecated

[damianwadley]

Again, as the RFC (which DeveloperRob linked earlier) clearly states:

The strftime() and gmstrftime() functions exhibit similar issues as strptime(), in that the formats they support, as well as their behavior, is platform-dependent. Unlike strptime(), these functions are available on Windows, though with a different feature set than on Linux. Musl-based distributions like Alpine do not support timezone-related format specifiers correctly. These functions are also locale-based, and as such may exhibit thread-safety issues.

That means (gm)strftime is deprecated because:

1. Behavior is platform-dependent
2. Features are OS-dependent
3. Problems with musl-based systems
4. Dependency on the current locale implies a lack of thread safety

At minimum, the communication to the developers has failed so documentation should be more clear about this kind of decisions in the future.

What should be clear where?

The online documentation has never been the source of why things are the way they are - that has always been a matter for the mailing lists (and the RFCs, of course). What the docs should definitely do is communicate changes when they're known.

And it does:

1. Function documentation is updated to include warnings about deprecation. These are prominently displayed at the top of the page, and in cases like for (gm)strftime these is even a mention of alternatives.
2. Given that these decisions are "made" during new major/minor releases, those respective migration/upgrade guides include a Deprecated Features page. Such as the one for PHP 8.1, which has this dedicated Date section that lists strptime, strftime, and gmstrftime, and even mentions some alternatives.

So: what documentation are you looking for?