setlocale

Posted: Sun Nov 12, 2006 12:39 pm

Down in mainfile in the function formatTimestamp there is a call to setlocale.
This is a built in PHP function as I understand it. I've been doing some performance testing and this function is a relative "pig" ... it takes over 2 tenths of a second where I'm testing it and of all the functions that are called in a typical Nuke "run" it is about number 3 or 4 in terms of resource consumption. This would be fine if it really did something but I'm at a loss to see what it does.

FormatTimestamp is called with a time parameter and returns a datetime in the format of: Monday, October 23, 2006 @ 12:53:55 EDT

The setlocale function takes "en_US" as a second parameter and I believe this is set on the administration preferences panel but I don't see any documentation or drop down for what the other values besides "en_US" would be. Does anyone know? If you pass something else besides "en_US" to it will it return a different value in $datetime? I followed the PHP manual out to various sites that are supposed to give the alternative values to "en_US" but I had no luck in even finding "en_US" on them.

I've experimented with running a test site with setlocale() commented out and it works just fine and boy that extra 2 tenths of a second makes it look fast. Smile

Comments? Would eliminating this foul up internationalization of Nuke or have other ill effects?

Posted: Mon Nov 13, 2006 10:39 am

Everyone is just jumping on this topic I see. Here's the results of some experimentation and reading. setlocale() is needed in any multilingual setting.
In Nuke it works in conjunction with the setting (define) for _DATESTRING that is in the language file for whatever language you are using. Here are three samples:

Code:

//define('_DATESTRING','%A, %B %d, %Y @ %H:%M:%S %Z'); 


define('_DATESTRING','%d %B %Y &agrave; %H:%M:%S %Z ');   


//define('_DATESTRING','%A, %d.%B %Y @ %T %Z');

for English, French and German respectively. $locale should be set to en_EN and fr_FR and de_DE respectively to correspond to those three datestrings. Then down in the function formatTimestamp the

"strftime -- Format a local time/date according to locale settings -- from PHP manual"

strftime function will use the $locale setting to format the datetime.

I guess conceivably we could see if the language is english and if multi-lingual is off and skip the setlocale under these conditions and save a few milliseconds but probably not worth the effort and testing that would be required in different environments. "The eagle does not hunt flies".

registered · Posted: Tue Nov 14, 2006 6:18 am

I did not jump in because my view of the PHP functions, which rely on locale data being installed on a host's server, is a bit "tainted". But, I need to take some time to review it in detail, and your analysis is very helpful.

Sells PC To Pay For Divorce Joined: Posts: 5661

well 2 milliseconds is 2 milliseconds right.... Laughing

you have to much free time fkelly....

Posted: Tue Nov 14, 2006 10:27 am

LOL, I'm retired Hitwalker.

But I said 2 tenths of a second and that's a heck of a lot different than 2 milliseconds. If it had been 2 milliseconds it never would have hit my radar. Next to the database connection, the single setlocale() function call takes up the most "resources" or time in a single nuke run. So it's not exactly trivial ... but still I would just be ignoring it except that I also think that it is problematic in terms of functioning properly or reliably.

As Montego said, the function is server dependent which means that it won't operate the same on all servers that Nuke is installed on. Here is a little program that I got from the user contributed notes in the PHP manual (but modified to be more useful). Run it on your server(s) and see what you get. On my Windows home machine with Apache I get no results. On one of Raven's hosts I get pages of output. What this means is that the setlocale is going to return different results depending on the locales the server has installed. To me that's problematic.

Anyway here is the code:

Code:

<?php





function list_system_locales(){


   ob_start();


   system('locale -a');


   $str = ob_get_contents();


   ob_end_clean();


   return split("\\n", trim($str));


}





// $locale = "en_EN";


$locales = list_system_locales();


foreach ($locales as $key => $value) {


    echo $key . ': ' . $value . '<br>';


}





?>

Now in terms of a solution, I am testing RN2.10 with the setlocale function commented out of the timestamp function. I believe that if your locale is set to en_US and you are never changing that you will probably be okay doing that. But I know it's not a very good solution for software that is to be distributed worldwide. There's got to be a better way, I just don't know what it is yet. There can only be one value of $locale set for a given site at a given time and I seriously doubt that any site changes it on the fly. So I'm just wondering if there is some better way to return the value of datetime that doesn't require using strftime which in turn depends on setlocale (but seems to work okay even if setlocale hasn't been run).

registered · Posted: Tue Nov 14, 2006 12:11 pm

Perhaps you could make the call to setlocale() a config file or config table driven option. I would guess that for most people, the server they have chosen to host their site is running a compatible locale. So only call setlocale() if they ask for it. Maybe if they provide a blank locale string, skip calling setlocale(). Just thinking out loud.

Posted: Wed Nov 15, 2006 10:59 am

Quote:

There can only be one value of $locale set for a given site at a given time and I seriously doubt that any site changes it on the fly. So I'm just wondering if there is some better way to return the value of datetime that doesn't require using strftime which in turn depends on setlocale (but seems to work okay even if setlocale hasn't been run).

You might want to trace this back and test with the site preference being set to en_EN and then see what happens when multilingual is turned on in preferences and then a logged in user selects a different language. To be honest, I am not even sure how nuke is using this in this case.

I would test both the news articles date/time format as well as the forums. These are using different techniques to format the dates.

registered · Posted: Wed Nov 15, 2006 11:35 am

Why not just use the date format you set in your forum profile. That's what we did. That way everyone can set their own time and dates.