[development] code proposal: localization of currency, ...

[Larry Garfield]

On Mon, 22 Oct 2007 10:21:16 +0200, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> On Sun, 21 Oct 2007 15:53:20 -0500
> Larry Garfield <larry at 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