Is PHP Intl extension thread safe?

Question

I read about locales in PHP and it seems that setlocale() has problems with threads. (I'm not too familiar with threads - the docs mention that it is not thread safe)

I would like to give my project the opportunity to deal with certain number formats, and the Intl extension seems interesting.

http://php.net/manual/en/book.intl.php

Should I expect the same problems that setlocale() uses the Intl extension?

Answer 1

Well, I was also curious, so I designed the test.

At first I tested setlocale() with these two files:

 <?php # locale1.php error_reporting( E_ALL | E_STRICT ); date_default_timezone_set( 'Europe/Amsterdam' ); setlocale( LC_ALL, 'dutch_nld' ); // awkward Windows locale string sleep( 10 ); // let sleep for a bit here echo strftime( '%A, %B %d, %Y %X %Z', time() ); 

and

 <?php # locale2.php error_reporting( E_ALL | E_STRICT ); date_default_timezone_set( 'America/Los_Angeles' ); setlocale( LC_ALL, 'english_usa' ); // awkward Windows locale string echo strftime( '%A, %B %d, %Y %X %Z', time() ); 

Then I performed them on two separate tabs. First, locale1.php , which sleeps for 10 seconds after setting the locale, giving us time to run locale2.php in the meantime.

To my surprise, locale2.php does not even allow you to change the locale correctly. It appears that sleep( 10 ) in locale1.php captures the Apache / PHP process in such a way that it does not allow locale2.php to change the locale. However, it nonetheless repeats the date, but is not localized as you expected.

Edit: Sorry, do it. It appears that locale2.php changes the locale and locale1.php and then prints the English date instead of Dutch after sleep. So it looks like it matches the expected behavior from setlocale() . / Edit

Then I tested IntlDateFormatter with these two files:

 <?php # locale1.php error_reporting( E_ALL | E_STRICT ); $dateFormatter = new IntlDateFormatter( 'nl_NL', IntlDateFormatter::FULL, IntlDateFormatter::FULL, 'Europe/Amsterdam' ); sleep( 10 ); // let sleep for a bit here echo $dateFormatter->format( time() ); 

and

 <?php # locale2.php error_reporting( E_ALL | E_STRICT ); $dateFormatter = new IntlDateFormatter( 'en_US', IntlDateFormatter::FULL, IntlDateFormatter::FULL, 'America/Los_Angeles' ); echo $dateFormatter->format( time() ); 

and then run them again on two separate tabs, as in the first set of files. This gives the expected results: while locale1.php falls off, locale2.php beautifully prints the date in US-English in accordance with American rules, after which locale1.php beautifully prints the date in Dutch according to Dutch rules.

So, concluding, it seems that Intl safe from this setlocale problem.

But also reason is Hyunming Kim's answer . I could not comment on this due to the lack of experience using Intl . I just discovered Intl .

Answer 2

Intl extension is safe and very useful if you work without working inside the framework.

For example, if you use Symfony2, your programs are likely to crash when using forms and validators.