<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