Fixing timezones in Drupal / Date

I'd add another action item -- adding a column to the user table to track the timezone name. The 'timezone' column there now is tracking the timezone offset. Removing or changing that would break lots of things in both core and contrib, so it might be best just to add a new column for this purpose. It needs to be fairly big varchar field, some of the timezone names are quite long. Once a column is available, it can optionally be filled in on systems with php5 support (or whatever else we use to make this work).

And we need a variable to track the site timezone name, since the current one, again, is only tracking an offset. Again, I worry about changing what we store in the existing variable because of its potential to break lots of things. It would be cleaner to just add a new one.

And the other reason to use new columns/variables for these values is that it will allow us to fall back to the current behavior on systems without php5 support -- using the offset.

I'm bring my proposed patch from http://drupal.org/node/11077 back here for more discussion. After digging into things more, here's what I think might work well:

1) Create wrapper functions for each of the new timezone functions that only work in php5, or at least the ones we want to support, i.e. drupal_timezone_identifiers_list() to wrap around timezone_identifiers_list().

2) In those functions test for php5 support and use the php5 functions if available, otherwise include a separate .inc file that has php4 alternatives that produce the same result. For instance, the .inc file needs to produce the same timezone list that timezone_identifiers_list() produces.

3) In the php4 file try using putenv('TZ=myzone') before calculating a timezone offset, then return it to the previous state using putenv(TZ'). This is one of the things to discuss, is this the best way to emulate timezone support on php4? Killes has created another system in the event module that will work whether or not putenv() works, but it is limited to only certain parts of the world and has no historical records like when daylight savings time changed in 1980. Everything I've read about timezones suggests that the most reliable method of calculating timezones will be using putenv() to use the built in servers libraries, which should be based on the Olson database. The biggest problem is that some servers may not have the libaries installed or updated and that servers using safe mode will throw errors if you try to use putenv().

4) Once we have a method for calculating timezones, change the user and system timezone settings pages to use the timezone name instead of the offset.

5) Update any code in core that was using the timezone offset and alter it to use the timezone name and calculate the offset.

Hey, guys. I've been thinking about the TZ problem quite a bit lately, and have had a few thoughts. Anyway, if nothing comes up in the next week or two, I'm gonna try to work on some code to help out. I haven't had a chance to dig into the core very deeply yet, but I hope to this next week. Here are a few thoughts I've had...

I noted in http://drupal.org/node/11077#comment-256171 that either I don't quite understand the patch right, or that it looks like the proposed patch is replacing one offset with another. That is each day cron takes the users zonename and calculates their proper offset. During DST, this would cause the incorrect display of times of posts during parts of the year in standard time. See the comment in the link for an example. This tells me that we should be calculating the display for each date based on when it was posted. Yes, it is a little more overhead, but it will be correct. Reading back over KarenS's last comment, it seems as though that's the way this is headed, so I apologize if I'm being redundant.

I also like her idea of emulating support for PHP4 until PHP5 can be required. I think in the long run this will be easier since we won't have to worry about supporting offsets and zonenames, then we can just remove the .inc in the future.

Inputting dates: so far I haven't seen anything that deals with the input of dates and times. For example, if a user is submitting an event. Is this expected to be handled by the individual modules? It seems like it would be nice to have that functionality centralized, too.

Since I know I've already typed quite a bit, this will be the last thing for tonight... Since it looks like there's an inclination to use the PHP functions to handle timezones, are we to assume that the users will keep their db's up to date? I would hope most package management systems (at least in unixy environments) would take care of this, but I don't know if they do. Also, does Windows/PHP deal with timezones properly?

In working on this, I was wondering if there was any interest in keeping numeric offsets as well. If not, then I'll switch all of the stuff running on PHP versions with timezone support over to true timezones. If there is, then I'll probably check to see if the parameter is numeric, and if not try to determine a true timezone. Checking if the timezone is numeric might be a good way to transition for modules that still use offsets. It would also allow sites that upgrade to keep the users' current offset settings. Anyway, I'm essentially going to try to follow the game plan that KarenS mentioned above, but will initially add timezone support for PHP5 with PHP4 falling back on the old method. Then once we figure out how to best support PHP4, it should be easy to change in the wrapper functions.

I am looking at this again now to see if there is anything I can propose that still might be able to slip into 6.x before code freeze. Here is where things stand, as far as I can see:

1) Native php timezone handling won't work until php version 5.2, and still requires that php be installed with the new functions enabled, so even once we get to the point where Drupal requires php 5, we can't assume that the native php timezone handling will be available. That means we need a fallback solution for sure.

2) The fallback solution probably has to be the current system. Creating another system from scratch would be very timeconsuming and would have to be done by someone who understands all this date and time stuff, and people who understand that are the ones who are most likely to have systems that support the native php functions, so why would they want to put in all that work?

3) If we have a fallback system that requires the current numeric offset, do we create a new field for the zonename (my solution) or try to use the current field to store both numeric offsets and zone names? Using the same field for both seems odd to me, but I guess we could. We would at least have to increase the size of the field if we do that -- zone names can be long.

4) My solution to use cron to update the timezone offset was clunky, I agree with that. If we don't do that we will either have both fields or a timezone field that might contain either numeric or string info and a function you can use to test if native timezone handling is enabled (drupal_handle_timezones()), so contribs would have to update themselves to check that and proceed accordingly in a way that will work whether the timezone is an offset or a string name. [Edit] That was a dumb way of putting it. If we don't update the timezone offset values for people using php 5, we just need to be sure both core and contrib are smart enough to ignore the value in that column (which will be wrong) and use the timezone name and timezone functions instead. We don't need to update it at all.

Also, everyone is asking why I didn't do anything with format_date(), but I was assuming that no changes would be needed if date_default_timezone_set() was used -- that is supposed to make all date() and mktime() and time() functions use the default timezone. So one approach is to set that for everyone where drupal_handle_timezones() is true and then leave everything else alone. If you read through the comments at http://us3.php.net/manual/en/function.date-default-timezone-set.php you can see there may be questions about how that affects they system in other ways. If we use it, I don't think any changes to format_date() are needed.

So:

1) Do we want to store both numeric offsets and timezone names in the same user column and expect contribs to check to see what is there and proceed accordingly?

2) Do we want to turn on date_default_timezone_set()?

[Edited] Oh yeah, one more thing. If we use the current timezone column for both offsets and zone names, that may make it harder for a contrib module to try to supply that info using some other method (like the way the Event module calculates timezones now). If we have two columns, one could have the offset value that core will be expecting for people who don't have php 5 and another where a contrib module could insert a zone name using some alternate method.

Columns and column names:

I think we definitely need two columns -- one for a numeric offset, as is used now for anyone with less than php5.2 and one for the timezone name for proper timezone handling. The current name, timezone, should really be the place for the timezone name. The current value, an offset, should really go into another column. So one option is to move the contents of user->timezone into user->offset and open up user->timezone for the timezone name. We can fix all the references to user->timezone in core and contribs will have to pick up the change.

Timezones in format_date():

We have a similar problem in this function as with the user table. There is already a 'timezone' argument which expects a numeric offset. There is also a new argument in 6.x for format_date(), $langcode, so if we want to add another argument for a timezone name, we'd have to add yet another argument to format_date() for the zone name, and that argument would either be tacked on after the $langcode argument or we would need to patch anything using format_date() to move the $langcode argument over. Both of those options sound bad.

The only other solution I can see is to try to use the existing $timezone argument for either a numeric offset or a timezone name, have the function figure out which one it is, and then execute the appropriate code -- either the current method for an offset or use native timezone handling for the timezone name. Having an argument that could be two such very different things is a problem for developers who need to keep it all straight.

Thoughts? I really want to get at least a basic patch submitted before code freeze.