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

[Karen Stevenson]

<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