Ilia A. wrote: > Well, that is true for any external variable not just locale. For example if > you export TZ variable in a threaded enviroment all threads would be > affected. Exporting a TZ would be even more dangerous since it would affect a > commonly used data, dates, which are used in majority of PHP script.
messing around with the process environment is one thing, using an official PHP function is a different story ... > I do not see how this issue can be resolved, unless PHP does some internal > enviroment variable tracking as well as internal locale tracking. environment variable tracking is not needed, PHP has just to implement its own versions of locale dependant functions, track requested locale internaly as a thread variable and leave the global locale setting alone there are about 20 functions that need changes applied, most of them just use toupper()/tolower() or ctype is***() functions which can easily be replaced only things like printf(), scanf() and strftime() are a bit more difficult. For printf() and scanf() we already have our own versions that we just need to modify, and for strftime() we should bundle our own version anyway, as there are way to much problems with esp. windows users not knowing (and not reading in the docs) that not all of strftime()'s format placeholders work in every strftime() implementation i've already assigned this to me as a task for this weekend, maybe i'll find time to publish a small RFC/Whitepaper about the issues at hand tomorrow (detailed description of planned changes, affected functions, list of bugs that will be solved by the changes ...) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
