On Sat, Jun 19, 2021 at 1:04 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 18/06/2021 22:16, Derick Rethans wrote: > > strftime is infected by thread unsafe locales, which is plenty of reason > to deprecate it, with additional pro reasons for doing so being its > disparate functionality among different os-es and libc's. > > > > Deprecation also doesn't mean removal, which won't happen until PHP 9, > giving developers plenty of time to move to a saner threadsafe locale API > based on intl/icu. > > > I think you're probably right, but I think in general deprecations > should be accompanied by much stronger migration instructions than > "there's a class over here that probably does what you want if you kick > it a bit". > > Like everything in ext/intl, IntlDateFormatter is rather complex, and > the manual relies heavily on links to the ICU documentation, some of > which are 404s. If you're saying my 276 uses of strftime() are "wrong", > it would be nice to have a clear message of what is "right", and what I > should do to "fix" them. > Yeah, I definitely see the concern here. In my corpus, most uses of strftime() are actually locale-independent and can be easily replaced by DateTime::format(). I guess these are only being used because calling strftime() is slightly more compact than calling DateTime::format(), which requires creating a DateTime object first. A small handful use a locale sensitive format, which would require IntlDateFormatter and its more complex API. I believe the equivalent for %B would be something like this: https://3v4l.org/1pNDi It doesn't help that the IntlDateFormatter API is un-great and doesn't allow you to directly create a formatter for a pattern without passing a number of irrelevant arguments. Regards, Nikita PS: I found this scary comment in the strftime() docs: https://www.php.net/manual/en/function.strftime.php#104043
