- Development - lists.drupal.org

Re: [development] code proposal: localization of currency, ...
by Karen Stevenson 23 Oct '07

23 Oct '07

No, the autotimezone module automatically sets the timezone offset using a fairly simple bit of javascript to automatically update the timezone offset in the user record. I'm talking about the timezone name. There is no javascript-only way to identify and set the timezone name from browser information. In fact, I spent quite a bit of time researching how to do it since the common wisdom is that it can't be done at all. But I finally stumbled on a way to do it with a combination of javascript and PHP5 by building on some example code from a presentation made by Derick Rethans (the maintainer of the PHP5 date functions). Plus, to do anything useful with the user timezone name, you also have to overload the site and user timezone settings to select and store the timezone name instead of the offset, and to do that you have to have a way to manipulate timezone names and offsets to present the selection list. And then of course you need new ways of manipulating dates that use the timezone name instead of the offset to do timezone conversions. I put this in the Date API because it all works together -- you need the PHP5 date functions or their equivalents to detect and store the timezone name, and you need a different way of handling dates to do anything useful and reliable with the timezone name once you have it. I can propose patches for the autotimezone module, but they would be radical changes to the way the module works. It would have to be something like a completely new version of the module that requires PHP5, that both updates the offset as is done now for backwards compatibility with with old-style date handling but which also detects and stores the timezone name for applications that can use that information. And it would have to overload the user and site timezone handling forms to list and store timezone names instead of offsets. And autotimezone would then become a required module for any application that wants to use PHP5 date handling or store timezone names in user records. If it seems like this belongs in autotimezone, I can propose patches to it. Karen ----- Original Message ---- From: Moshe Weitzman <weitzman(a)tejasa.com> To: development(a)drupal.org Sent: Monday, October 22, 2007 7:18:17 PM Subject: Re: [development] code proposal: localization of currency, ... @karen - I suspect you have reimplemented autotimezone module - http://drupal.org/project/autotimezone. if you have any improvements, consider posting them in its issue queue.

2 1

Re: [development] code proposal: localization of currency, ...
by Karen Stevenson 23 Oct '07

23 Oct '07

<clip> > 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. ... > Once you ask... well you don't need the Olson bag with you. > Computations with dates should be a language task not drupal task. </clip> I'm not quite sure how a thread about localization of currency drifted off into date handling, but if we're going to debate how dates should be handled I guess it's time to jump in: * In PHP5 we can do lots of intelligent things with timezone information, including getting dates that automatically adjust for daylight savings time without any need for any intervention by either users or administrators. PHP5 date handling could certainly be expanded on, but it is still significantly better than PHP4 methods. * In D7, we will want to quit asking users what their *offset* is (the current behavior) and start asking what their *timezone* is. Once we know that, in PHP5 we can make the necessary conversions. * PHP5 timezone handling gets its power from the Olson timezone database. It is inaccurate to say "once you ask you don't need the Olson bag with you" -- you still need some method of converting dates from one timezone to another where you can be sure your conversion has been adjusted to the right value (and you need a method that works even when the site and the server and the user use different timezones and one or more of the timezones need adjustments for daylight savings time). And keep in mind that you can't just store the user's offset and use that as the adjustment for all future dates, because the offset can be wrong if the user is currently in daylight savings time but the date you are adjusting is not. * Some part of this must go in core. We currently attempt to do timezone adjustments, but sometimes get it wrong because of the problems working with dates in PHP4, so anything we can do to improve on that must also go into core. Unless we get rid of timezones completely and use GMT for everything, which I'm sure is *not* an acceptable solution :) I took a stab at getting better date handling into core in D6 but it didn't make it. And killes and others have tried to get it into core in earlier versions. It will be much better to do it in D7 anyway, because that way we can use PHP5 date handling. In earlier versions it was going to require some nasty cludges to work right in PHP4. BTW, although we don't need to guess the user's timezone, since we're just going to ask them, I have come up with a method of making an intelligent guess of the user's timezone using a combination of PHP5 and javascript that could be used to pre-populate timezone info until the user verifies it. I have code to do that in the HEAD of the Date API right now and hope to set up a page that people with different browsers and systems can use to test how well it works. Karen

2 1

Re: [development] code proposal: localization of currency, ...
by Larry Garfield 22 Oct '07

22 Oct '07

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

2 1

anyone have better solutions then removing the JS compressor?
by Gábor Hojtsy 22 Oct '07

22 Oct '07

Hey, People encountered some problems with the JS compressor, which seem to make valid JS files invalid in the process of compression. The proposed solution is to remove the JS compression (keeping the aggregation in place). Anyone has better ideas? http://drupal.org/node/183940 Gabor

1 0

Re: [development] code proposal: localization of currency, ...
by Larry Garfield 22 Oct '07

22 Oct '07

On Fri, 19 Oct 2007 12:22:22 +0200, Ivan Sergio Borgonovo <mail(a)webthatworks.it> wrote: > #tech > > I think this kind of support should be available independently from > i18n for mono-language sites and I gave some example on how it could > be used even without i18n support but if no sign of > acceptance/suggestions come out I'm going to write it as if it > was part of i18n with function names in their own "namespace". > Starting with the right foot and giving them a more "corish" name > would make it easier to be included in module development. > > If no suggestions for better acceptance comes out shortly I'll start > to write an interface for setting up this stuff and the functions. > If someone is aware of some more strangeness of float/currency > formatting let me know. > > Suggestions for the formatting string for currency are also welcome. > Especially a way to specify character that shouldn't be outputted in > case the number is positive. > > Is there anything more than: > general > scientific > accounting > notation for float/currency. > I'd think that accounting rules are rather specific to each country > and accounting modules would be specific for a country and let the > developer take care of the problem independently of the > interface/language. > As well as I'll keep scientific notation in US format. > Anyway in spite of adding one parameter to format_number I could just > write format_scientific and format_??? later to avoid messing up with > signatures and over planning. > > At this moment I'm aware of people using different char for grouping > and different size of grouping (eg. 1 23 45 to write what US people > would write as 12,345). > Providing support for such formatting is a bit more overhead cos you > can't use directly php format_number. > Can anybody confirm that there are some places where they group > differently? Is anyone scared about the extra overhead of an if > clause if grouping is != 3 so that most common case could be > optimised with format_number and everything else use a custom > function? > Is it worth to support this cases? > Still they can be supported later without changing the signatures of > the functions. > > BTW I'm already using i18n and custom date format for each language > and it works like a charm > > > thx > > > [1] as a matter of fact Drupal is providing one of the best framework > for internationalisation I'm aware of. It doesn't mean it can't be > improved. > > -- > Ivan Sergio Borgonovo > http://www.webthatworks.it I've been pondering this, and I think currency has a lot of parallels to time management. Consider the PHP 5.2 DateTime object. It stores the timestamp internally somehow, but you can't get to it. A time unit can be formatted, or mutated to another timezone object. Those operations are completely orthogonal. The timezone mutator rules also change quite regularly, thanks to national governments that can't make up their minds. Neither of those is usefully related to language or locality. Currency is similar. It can be formatted in a number of ways (with/without decimal, with comma-dot or dot-comma separation, with spaces separation, with currency symbol, with currency abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality. Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-) --Larry Garfield

2 9

Re: [development] What's a critical issue
by Piermaria Maraziti 20 Oct '07

20 Oct '07

At 01.04 20/10/2007, you wrote: >How much does your hour cost? A lot, I'm a very experienced linux user :-) >I wanna pay you, but you sign a contract >and advance the same amount I'll pay you, in case you don't finish the >job! And, yep, I really installed a couple servers in an hour also if, normally, it takes some more. But a simple configuration and hardware that has no problems is as simple as that to me. Obviously, if you have a lot of quirks: raid+lvm2, strange partitionings, attached storage, cluster configuration... various hours, one day or more is likely. I was also microsoft certified - my *opinion* is that for serious things, for websites that might be attacked by hackers and for servers with critical performance issues, windows is weel behind linux... however I do not make religious wars about this. Also, I think we're well out of topic - I won't answer more if we don't return to drupal issues :-) Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria(a)maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it

1 0

Re: [development] What's a critical issue
by Piermaria Maraziti 19 Oct '07

19 Oct '07

At 17.50 19/10/2007, you wrote: >Linux + OpenLDAP + Apache + (Exim or Postfix) = hmmmm how much? and >with what integration? 1 hour. Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria(a)maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it

2 1

What's a critical issue
by Karoly Negyesi 19 Oct '07

19 Oct '07

Hi, I think that nothing concerning postgresql or Windows can be a critical. Regards, NK

14 19

Debugging updates
by Karen Stevenson 19 Oct '07

19 Oct '07

Does anyone have ideas for ways to debug update functions in the install file figure out what's going on when they don't work as expected or when I get reports of problems? Is there any way to see the query logs that the devel module creates from within updates? If I use update_sql() I can tell what queries ran, but there are times when I need to use db_query() instead and I can get no clue to what is going on when that runs. And I can't find any way to display messages back to myself or see results of print_r() or any of the other things I do elsewhere to debug scripts. I've tried to execute the update() script directly from within a normal page, but that won't work either. Ideas welcome! Karen

7 6

Re: [development] development Digest, Vol 58, Issue 35
by Kai Wang 19 Oct '07

19 Oct '07

Hello I'm looking for a company to develop 3 Drupal sites for me. The 3 sites grow in level of complexity. The first site is a simple Blog based site that supports various media types. Site 2 is a social networking site inheriting functions from Site 1 Site 3 a mashup site inheriting functions from Site 1 and Site 2. If you are interested please email me with your email address and I'll reply back with a spreadsheet of detail requirements. Thanks Kai kaiwang _at_ yahoo _dot_ com

1 0