[php-src] Issue #11190: Undeprecate strftime() because the rationale for deprecating it doesn't make sense
| From: | mikkorantalainen | Date: | Fri, 05 May 2023 13:39:31 +0000 |
| Subject: | [php-src] Issue #11190: Undeprecate strftime() because the rationale for deprecating it doesn't make sense | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-244378@lists.php.net to get a copy of this message | ||
Issue: https://github.com/php/php-src/issues/11190
Author: 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.