Re: [development] code proposal: localization of currency, ...
On Mon, 22 Oct 2007 10:21:16 +0200, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Sun, 21 Oct 2007 15:53:20 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
for DateTime in general, I recommend this page:
http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetime
zone/
Finally I read it fully. It looks Zend is going Microsoft if you read one of the comments ;) I've vague memories of Windows timezone setup and it doesn't let you guess there is such a mess behind.
Anyway I can't find a place in drupal for such a beast. (OK, I may be wrong... but then tell me...).
The most obvious to me: Instead of users selecting a timezone offset, they select their location from the built-in Olson database. We then use DateTime and DateTimeZone to translate the base time we store into $users timezone. It's more accurate than just an int offset, and handles Daylight Savings time for us as well. $date = new DateTime('@'. $node->created); $date->setTimeZone(new DateTimeZone($user->timezone)); echo $date->format(...); // This probably gets wrapped in format_date() or something that understands Drupal's "short" and "long" dates.
There is the time of the server and there is the time of the user. You don't know where the user is and you've to ask which timezone he prefer. Guessing where the user is and which timezone he is in, is a risk that doesn't fit to much in core.
Who ever said anything about guessing? Of course you ask the user what their nearest Olson location is. Geo-mapping by IP would be way too unreliable. But once you know that information, which is more useful than just a GMT +/- number, PHP will do the timezone translation for you, including, I believe, Daylight Savings. That's a feature that's been requested numerous times.
Once you ask... well you don't need the Olson bag with you. Computations with dates should be a language task not drupal task.
Dates have absolutely nothing to do with language. I'm setting up a Drupal site now for a community site that is run in American English, but has people from 12 timezones, probably more if you consider that Indiana and Arizona are not in their "normal" timezones because of Daylight Savings, and similar world weirdness.
I've the same feeling with currencies.
As has been stated, currency has nothing to do with language, either. There's a dozen Spanish speaking countries in the Americas alone that have different currency formatting rules.
Well since I only started talking about it 2 days ago, not that I know of. :-) Really, I was just throwing out an alternative approach to take that would offer more long-term flexibility for currency handling.
Unless you take in Zend stuff I see no way to exploit all the info you generally have in locale and locale settings are shared across threads in the same process.
Huh? PHP on the web is not threaded. What Zend stuff are you talking about? I don't even know what you're talking about. :-) --Larry Garfield
On Mon, 22 Oct 2007 12:32:29 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
Anyway I can't find a place in drupal for such a beast. (OK, I may be wrong... but then tell me...).
The most obvious to me: Instead of users selecting a timezone offset, they select their location from the built-in Olson database. We then use DateTime and DateTimeZone to translate the base time we store into $users timezone. It's more accurate than just an int offset, and handles Daylight Savings time for us as well.
$date = new DateTime('@'. $node->created); $date->setTimeZone(new DateTimeZone($user->timezone)); echo $date->format(...); // This probably gets wrapped in format_date() or something that understands Drupal's "short" and "long" dates.
OK once they set it... it will "follow them". Got it, thx.
Once you ask... well you don't need the Olson bag with you. Computations with dates should be a language task not drupal task.
Dates have absolutely nothing to do with language. I'm setting up a Drupal site now for a community site that is run in American English, but has people from 12 timezones, probably more if you consider that Indiana and Arizona are not in their "normal" timezones because of Daylight Savings, and similar world weirdness.
Format of time. And didn't we agree that timezone and format where orthogonal?
I've the same feeling with currencies.
As has been stated, currency has nothing to do with language, either. There's a dozen Spanish speaking countries in the Americas alone that have different currency formatting rules.
You've to guess at some point... language is a good starting I think. Then they can tune it. Somehow you should have a rough idea of your audience... maybe the default currency format for Spanish in Latin America may be the same as US. If you expect to have your main Spanish audience from Latin America, you may set the currency format accordingly. I feel it's better than just default to US format everywhere with every language. I'd like to build a path to add pieces a bit at a time and have something that won't mess with further improvements. Then you could delegate the choice of the default "locale" to "smarter" functions (eg. GeoIP, GeoIP + Language, Language + aruspices...).
Well since I only started talking about it 2 days ago, not that I know of. :-) Really, I was just throwing out an alternative approach to take that would offer more long-term flexibility for currency handling.
Unless you take in Zend stuff I see no way to exploit all the info you generally have in locale and locale settings are shared across threads in the same process.
Huh? PHP on the web is not threaded. What Zend stuff are you
It looks as on IIS it is multi-threaded. I can't swear on it.
talking about? I don't even know what you're talking about. :-)
http://www.nabble.com/Zend_Currency:-toCurrency-cutting-off-numbers--t460321... http://framework.zend.com/ -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (2)
-
Ivan Sergio Borgonovo -
Larry Garfield