Posted by gylle on August 6, 2002 at 7:41am
Jump to:
| Project: | Drupal core |
| Component: | user.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | al |
| Status: | closed (fixed) |
Issue Summary
A "timezone" is associated to a user account. However, the timezone is oversimplified. It does not suffice to say what the current timezone is e.g., GMT+2 because this doesn't take daylight saving time or other changes in account.
Comments
#1
changing this to a feature request, and making the title a bit friendlier
#2
Anyone have any idea how to make a system account for timezones without being horribly complex? IMO timezones are a mess and nothing something we can really do anything about, its easier to have the users update possibly twice a year.
#3
A bit of research yields the following Javascript function which can fomat all dates according the time of the user's PC.
-------------------------------------------
The Date object has a method getTimezoneOffset
which returns the difference to GMT time in minutes. For instance in Western Europe during summer time
var now = new Date();
alert(now.getTimezoneOffset());
shows
-120
---------------------------------------------
I'm not sure it is worth it, but you could have the server output everything in GMT and then javascript manipulates the date for the user's local time. The big benefit is that the user never has to be bothered to give a time zone pref. It just works!
Please don't reply to this item saying that javascript is evil. Javascript is a programming language. I cannot be evil on its own. Smart, capable programmers use javascript to make the browser an even greater tool.
#4
after looking here:
http://www.php.net/manual/en/function.setlocale.php
http://www.php.net/manual/en/function.strftime.php
http://www.opengroup.org/onlinepubs/7908799/xbd/locale.html
I think we just need to
setlocale(LC_TIME, $user->locale);and then use strftime() instead of date(), for example in common.inc::format_date()
this _should_ take care of daylight and traslations among other things. we'd probably need to store dates in GMT.
btw my recent locale patch adds user locale instead of language (it_IT instead of it)
#5
This is really a bug, marking it as such. Assigning it to me, as I want this fixed in time for summer. ;)
#6
Fixing this is a much bigger job than I thought it'd be.
Turns out it has lots of implications for how mail gets handled, etc.
This needs quite a few hours spent on it - it's not a fifteen minute job. Fixing this will also have an impact on how the multilanguage and locale modules work, and careful consideration needs applying regarding charsets and the like.
#7
marking as a feature request (again).
#8
Good grief, this is complicated - it's far from an easy setlocale patch.
Practically no one has solved this problem propely - most sites simply say "GMT" on them, or whatever. The reason for this is that the situation is very complicated. [1]
It would seem that someone (erm, me?) needs to write a daylight savings class/function for PHP which is general enough to work something like this:
This would provide English text dates (e.g. "April", not "Avril"), but in the French timezone, which would cater for English people currently in France or whatever.
I'm unsure what form the country should really take - probably a list of standard country codes, I should think. Some will need to be special, though - like Arizona, which doesn't do daylight savings time.
Note that this isn't going to work reliably for browser locale strings (although you'd set up a best-guess mapping from locale -> country), so it will only be very good for people who have registered and specified which country they're in. We should probably modify things when we do this to automagically pick up sensible timezone/country defaults from the user's browser locale anyway.
[1] http://webexhibits.org/daylightsaving/g.html
#9
I would offer the following sequence for the time zone setup:
There's an extra parameter
is_dstfor the usual mktime() function which may help, but it is bind to locale, as I understand, so we will have to reload page at least once to let php check if selected timezone is in DST. Not good.For different date/timezone manipulations exists a package from Pear PEAR::Package::Date:
So there may be no need to actually write the class, but it still costs something like an hour or two to glue all the components together. I could help with the client-side script for dynamic form generation-display if my help will be useful.
#10
I suggest following solution: Add checkbox named DST to user account settings; and on every page request or login check timestamp (when was user last online). If beginning and ending days of DST are betweeen NOW() and timestamp, change user timezone.
#11
Arizona really need to observe DST during the summer between April and October. To assure that they'll have a good taste of having daylight/twilight later in the evening if the government allow to use DST which means still on the MST. However, since Arizona do not observe DST which means they are on California time (PST) will get dark early and California will still have daylight a little while longer. If Arizona were smart enough, they can tell the local government to move the clock 1 hour foward and still be on MST, not on PST. The Indian Reservation do observe daylight savings is on MST and the rest of the state is on PST. You may want to check on www.sunrisesunset.com and most of USA have daylight after 8pm. Best if the people in the state of Arizona to persuade the government or vote.
#12
I haven't tested CVS or 4.4.0-rc, but this is definately still a problem with 4.3.0. Has anything been done to counter the problems with DLT after 4.3.0?
#13
As of version 4.4.1 final this bug/feature is still not implemented correctly. It's sort of a big deal... anybody making progress with this issue?
#14
In Linux and most OS's you choose which city you want your time to go by. This is really the only "correct" solution - I know in places in India they are +5:30 UTC so the current way Drupal doesn't wouldn't work at all for them.
The JavaScript solution makes a lot of sense as long as there is something to fall back on.
#15
I have just implemented dst handling in event module. You can view the results of this here: http://civicspace.advomatic.com/event/dst
The javascript solution is a good one. Before we get to full dst support however the offset handling in core has to change. We are going to push to get the timezone list we are using in event into core for sitewide and user timezones. We also must integrate the dst timezone handling functions into core.
Once this happens we will be able to take this last step of setting user's timezones with a javascript method to clean up the last bits.
Interested parties should please review the timezone include file in the event module directory and give feedback. Since this is the first DST implementation to hit production for drupal we are going to push for its inclusion into core. Obviously once its there things get easier to tweak and harder to overhaul.
Thanks....
#16
finally, some developer less lazy than myself has implemented the javascript method that I described here. Nice work, LuleLast!. See http://cvs.drupal.org/viewcvs/drupal/contributions/modules/autotimezone/...
#17