[drupal-devel] [task] Introduce Daylight Saving Time for Drupal

Wed May 4 18:13:08 UTC 2005

Issue status update for http://drupal.org/node/11077

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     normal
 Assigned to:  crunchywelch
 Reported by:  killes at www.drop.org
 Updated by:   tostinni
 Status:       patch

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

tostinni

Previous comments:
------------------------------------------------------------------------

September 25, 2004 - 22:01 : killes at 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 25, 2004 - 23: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 - 09: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 26, 2004 - 17:54 : killes at 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 27, 2004 - 16: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 - 15:38 : killes at 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 - 11: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 - 11: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 - 11:06 : syntaxerror

Works beautifully.. I'm going to work on getting this to work with
event.module.

------------------------------------------------------------------------

May 4, 2005 - 12: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=1.1&view=markup)
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!