Issue status update for http://drupal.org/node/11077 Post a follow up: http://drupal.org/project/comments/add/11077 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: crunchywelch Reported by: killes@www.drop.org Updated by: glen Status: patch one idea, maybe use mysql timezone tables that are available since mysql 4.1.3? http://www.visionwebhosting.net/mysql-web-hosting/page0403.htm not sure how it's possible with licensing, but original tzdata is GPL (at least according to Fedora Core 2 tzdata.spec) then mysql data table contents should be too GPL. good side is that it should work for windows too http://dev.mysql.com/downloads/timezones.html glen Previous comments: ------------------------------------------------------------------------ September 26, 2004 - 06:01 : killes@www.drop.org Attachment: http://drupal.org/files/issues/dst.patch (6.04 KB) Many people have wanted to have a Daylight Saving Time setting in the past. If we use the "server time" modell (all times are displayed the same around the world) this isn't all that hard to do. I found a lot of usefull information here: http://webexhibits.org/daylightsaving/g.html The patch introduces a new DST setting and uses it if the "Configurable time zones" setting is switched off. ------------------------------------------------------------------------ September 26, 2004 - 07:40 : gordon This is a lovely patch, but you do realise that you have opened a can of worms. Daylight saving is a messy business, I had to write the Contestable Electricity billing for a company here in Australia which had multiple installations in multpile timezones, all with different daylight savings rules, which impacted upon the bill. The way that dst is legistated is very messy and here is Australia it is very messy. Daylight savings don't follow state lines, as some towns that are very close to the border may choose to follow the only the daylight saving period of the next state, and when we had the olympics NSW went into daylight savings months before anyone else. There are other examples of weird things like even the 1 hour forward is not also true. I know that in the 1999 change to daylight savings there was a small set of islands north of New Zealand that went ahead by 2 hours as they wanted to be the first into 2000.

From what I can see of your patch it only allows for a single daylight savings period for the entire system. Their can be situations where there can be users from multiple countries and in different timezones/dst.

I think that entire timezone system needs to looked at again, and maybe re-implement it so that it will allow for dst. Maybe make it a bit more user friendly so instead of setting up the timezone by name much like how operating systems do it, and then this will automatically work out the timezone. +1 for this is something that would be good, but it still needs work. ------------------------------------------------------------------------ September 26, 2004 - 17:13 : Anonymous The patch works as it is now. I had good reason to limit its capability to the setting where users cannot chose their own timezone. ;) I also assume that a server administrator knows if he has dst or not. I also didn't (yet) cater for all countries where dst is in use mainly because some insist on not giving a sensible rule for the change dates. ------------------------------------------------------------------------ September 27, 2004 - 01:54 : killes@www.drop.org Attachment: http://drupal.org/files/issues/dst_0.patch (6.04 KB) The last comment was mine. After a code review by Kjartan I provide a slightly improved patch. I want to stress that solving the DST issue in a "suits everybody" manner isn't the intention of this patch. It solves the problem for people who have chosen to let all times on their site be displayed in the server's time setting. By covering a large portion of the earth's landmass I hope to be able to help most site admins. It would be possible to extend the patch to allow users to chose their DST setting, too. In my experience, however, users tend to not care about time settings at all. This may be EUrocentric though, as we have only one time zone. Feedback is welcome. ------------------------------------------------------------------------ September 28, 2004 - 00:12 : drumm +1

From a code review I think this is an excellent solution. Could use a little more comments in the section that sets $node->date to explain the (probably good) reasoning behind that chunk of code. I don't have anything resembling a good set of tests so I did not apply the patch and try it.

------------------------------------------------------------------------ January 25, 2005 - 23:38 : killes@www.drop.org I just want to point out that this patch still applies and would make for a fine feature for Drupal 4.6... ------------------------------------------------------------------------ January 26, 2005 - 19:46 : alliax wouldn't hurt to have this feature in upcoming drupal. I would use it for sure, my users are from the same place, with dst ------------------------------------------------------------------------ April 28, 2005 - 19:12 : Sage This is an incredibly useful feature and I would like to see it incorporated into the next release (current release is 4.6.0). ------------------------------------------------------------------------ May 4, 2005 - 19:06 : syntaxerror Works beautifully.. I'm going to work on getting this to work with event.module. ------------------------------------------------------------------------ May 4, 2005 - 20:53 : crunchywelch I have just discussed with killes and rorris an enhancement to this patch which I will implement. We have proposed putting the ical timezone db (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ical/ical.sql?rev...) in core. We will implement a DST field in that db for each zone which coreesponds with the zones in killes' patch here for dtermining whether a zone is currently in dst or not. Currently, the 5 zones in the drupal_is_dst() function in this patch will be the only regions assigned to timezones. If more regions are desired they can be submitted by the community. To be clear, this must be implemented before additional development on ical/event.module can proceed properly. We would like this to be in core for 4.7, and move one more step with timezone handling in event module to use this as well. Discuss! ------------------------------------------------------------------------ May 4, 2005 - 21:13 : tostinni I agree to put more specific region to DST as it's easier for someone to know which city DST he belongs than which DST Zone (Pacific Standard Time...). I like pretty much the way that windows manage this. +1 ------------------------------------------------------------------------ May 5, 2005 - 05:45 : Jaza The patch looks good... however, it doesn't take into account the fact that in Australia, DST starts and ends at 2am on Sunday morning. So these lines:     case 4: // Australia       // start of DST (last Sunday in October)       $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + $timezone;       // end of DST (last Sunday in March)       $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + $timezone;       break; Should read:     case 4: // Australia       // start of DST (last Sunday in October at 2am)       $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200 + $timezone;       // end of DST (last Sunday in March at 2am)       $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + 7200 + $timezone;       break; There are also a whole lot more countries (and their specific DST rules) on http://webexhibits.org/daylightsaving/g.html than are implemented in this patch. I'd ultimately like to see an admin interface to let the webmaster add additional DST rules for whatever country they live in (or are developing for). These rules could be entered in raw PHP, or using a somewhat friendlier interface. Jaza. ------------------------------------------------------------------------ May 25, 2005 - 09:11 : Steven +1 on this patch. Catches most cases and at least provides a base for others to work on. ------------------------------------------------------------------------ May 25, 2005 - 10:13 : gordon Do not take this the wrong what, but when it comes to dst, this is exemely simplisict. What would be the best method of doing this is to use the Zone Info files from libc. These not only have all the dst splits, but also all the timezones, and would be the most acurate. Have a look at Sources of Time Zone and Daylight Savings Data [1] whcih has pointers to where all this information is. Did you know that Australia has 21 different Timezones and DST areas. If you could enter the same information from tzdata then this would be the altermate dst system [1] http://www.twinsun.com/tz/tz-link.htm ------------------------------------------------------------------------ May 25, 2005 - 15:25 : jhriggs There has sure been a lot of talk about DST and time zones lately. All I ask is that we hold off on committing anything for a bit. I am currently working on a project that will hopefully fix this issue completely, correctly, and once and for all. :-) I am in the process of writing a pure PHP library that will be released LGPL that uses the /real/ zoneinfo data files to handle any date (not just Unix timestamps) in any time zone. With this, site admins and/or users will be able to select their real time zone (America/New_York vs. our current GMT -500) and DST will inherently be handled without users having to change their settings. Much of the grunt work is already done. I still have to put all of the pieces together and make sure everything is well documented. As soon as I have tested everything to my satisfaction, I will role a Drupal patch that we can hopefully get tested and committed ASAP. Of course I want to see this get into Drupal first! ;-) I hope to have everything completed in the next couple of weeks, but based on the way things have been going lately, I can't make any promises. It will definitely be done before 4.7, though...whatever it takes! ------------------------------------------------------------------------ May 25, 2005 - 15:47 : gordon +1 This sounds great, but I think we will still need a pure php version that will be able to be used on hosted web sites where we will not be able to get you library installed. It doesn't need to be as effient as the php extension, as sites that at that big will be self hosted and be able to install this library. One question. Does you extension run on windows. If it does this is another reason to have a pure php version. This is really the method that should be employed. ------------------------------------------------------------------------ May 25, 2005 - 15:53 : jhriggs When I say "library," I just mean a collection of PHP files as opposed to a single file. There is nothing to be installed like an extension. This is pure PHP that will simply be part of the distribution (a handful of .php files placed inside includes/zoneinfo or something like that). As this is pure PHP, it will work anywhere PHP does. This will essentially give us the benefit and functionality of using the TZ variable on Unix without all of the problems associated with that (i.e. not knowing what zones are available and what there names are, not being available on Windows, etc.). ------------------------------------------------------------------------ May 25, 2005 - 16:27 : gordon This sounds good. If you would like someone who has done alot of stuff with timezones and dst (mainly in the contestable electricity inductry in australia, which is required for billing), I would be quite happy to take a look. The only problem that I see is that it sounds a little too messy for core. maybe this could be made into a contributed module that can be installed if people need the correct timezones. However this is how the dst and timezones need to be done if we want to get them correct. As I said before and I couldn't believe it, Australia has 21 different timezones and dst areas. The timezone database needs to be maintained. ------------------------------------------------------------------------ May 25, 2005 - 17:41 : killes@www.drop.org jhriggs, gordon: Please have a look at crunchywelch's dst implementation for event.module (in 4.6 and cvs). We intend to push this into core. ------------------------------------------------------------------------ June 28, 2005 - 23:11 : mfb Great! event_timezones.inc definitely needs to be in core, as it would be used for both user and site configuration. But it should include everything from the unix zoneinfo libraries, e.g. timezone abbreviations used by strftime(), so you can display "PDT" or "PST" instead of "America/Los_Angeles". so, a complete port of the zoneinfo libraries to PHP is probably what is needed. This would be used for site config, user config and events.