Last modified: 2008-12-22 21:55:29 UTC
I propose to add to the recently discussed "single-login" (one user account accross several wikipedia servers) the following feature regarding a single timezone setting for such users: One user lives usually in one TIMEZONE linked to a location and having certain properties regarding "timecorrection" value and daylight saving time changes twice a year. I wish to get rid of the manual setting of my timezone (timeoffset to UTC) when I have a single-login; the timezone setting should reflect not only the tiemcorrection to UTC, but also the changes according to national or international or local daylight saving time changes. It can be linked to a country code for most of the countries and for huge countries like the U.S.A. we need a more detailed setting.
I fail to see what this has to do with single-login. Pruned unrelated items from summary.
Changed pointer to page http://meta.wikimedia.org/wiki/Automatic_timezone_selection . Brion: you are right, I agree. Tom
Is there anyone dealing with enhancement feature ? It would be nice to have a quick solution which could be patched into running wikis (to adjust timezones automatically - do we have a script for this ?) Okay, I understand that not all users can simply get a (-01:00) offset to their timecorrections, but perhaps someone has a neat solution.
I think, that TIMEZONE is a user option and when the wiki would also know the country, any change from daylight saving time and back for certain users can be automatically done by the wiki.
Bring forward / follow up posting In four weeks, most of the US states and also European countries will change to daylight saving time ("Sommerzeit") --> timezone offset of many users need to be adapted individually. What I proposed within this enhancement report was, to switch timezones automatically according to the affected countries (for users who have opted-in such a new method). Basically and allow me to repeat: if a user lives in country X and has indicated this in a new user preference option, and has opted-in, then the change to or from daylight saving time could be done automatically by the wiki software. So, the wiki needs to know the country, in which a user lives, instead of the timezone. The implementation of this enhancement requires two new options in addition to the old option in user preferences: * new * "user wants to stick to UTC" (proposed as the new default for new account) * new * "user wants local time of country XY"; country = XY * old * "user wants to have fixed offset to UTC"; timezone/offset = hh:mm (this is the current method) See also http://meta.wikimedia.org/wiki/Automatic_timezone_selection - for commenting
[Changed summary to better reflect what's being discussed. It's not about "automatic selection" so much as a different way of specifying (location as opp. offset), and an automatic adjustment of the offset based on that specification.] There's probably a neat way of dealing with location->{offset and DST} within PHP but for the curious, I followed bread-crumbs from the GNU C library ("glibc"/"libc6") to a package called "tzdata", which can be retrieved from ftp://elsie.nci.nih.gov/pub/ Not only does this contain extensive details of offsets and "savings" for geographic locations, it has them throughout history as well. Just reading through the files, with their copious comments and historical notes, is kind of fascinating... :)
I just want to bring this forward - there are just a couple of days left until the time shift to daylight saving time ("Sommerzeit"...). Wouldn't it be great to help many of the Wikipedia users by adapting the time offset automatically (after they have set their location timezone, which is neither forseen in the 1.3.x nor 1.4 ) ? I just want to encourage some of you to eventually write a "sniplet" to adapt for the majority of users (US citizens and Mid-Europeans) the time offset next week when it changes: automatically. Just an idea.
(In reply to comment #7) > I just want to encourage some of you to eventually write a "sniplet" to adapt > for the majority of users (US citizens and Mid-Europeans) the time offset next > week when it changes: Nice though this would be, I very much doubt that this could be implemented in time for this changeover, for a number or reasons: * Firstly, this is a fairly major change (involving, for one thing, storing the preference in a completely different way), and 1.4.x is "frozen" for new features already; it's therefore most likely to come in 1.5, or at best after the formal release of 1.4.0 * Secondly, in order to actually be useful, every user would have to change over to specifying a location rather an offset (doing this automatically wouldn't be appropriate, as we wouldn't be able to tell apart multiple locations with the same offset but different "DST" rules). Granted, at least some of those affected will go in and correct the offset anyway (and probably spot the new option), but that still means the first *automatic* adjustment would be this autumn at best. * Thirdly, and most importantly, there just aren't enough active developers, and this isn't a high enough priority, for it to be realistically developed and tested in such a short time. It is a nice idea though, and if I get round to it I'll have a look at what implementing it would involve, with an eye to it perhaps being in place (for those who've spotted it) by the *end* of summertime.
(In reply to comment #8) > It is a nice idea though, and if I get round to it I'll have a look at what > implementing it would involve, with an eye to it perhaps being in place (for > those who've spotted it) by the *end* of summertime. Rowan, thank you. I created this bugzilla in September 2004, just two weeks before the last time change, and my only intention was now to bring it back to our mind, which was successful. Perhaps we all find a solution in the coming months (I'll help to do this). Thanks anyway for your appreciated comments. Tom
Summary: We could start something by using the TLD suffixes of the users' e-mail addresses, as .DE .CH .FR .CH .AT addresses and many more could used as a rough indication, in which timezone these user "live" !! !! All of them needs certainly a time shift tonight. Long version: We already have this bugzilla for drafting a framework to allow *automatic timeshift* adjustments. Changing the user data is once needed, because we currently have a time*offset* value, but better need *location* information. User entries with *location* information could be automatically changed twice a year (goal of this bugzilla). Any volunteers to write something ? Ad-hoc proposal: We could start something by using the TLD suffixes of the users' e-mail addresses, as .DE .CH .FR .CH .AT addresses and many more could used as a rough indication, in which timezone these user "live" !! !! All of them needs certainly a time shift tonight.
(In reply to comment #10) > Summary: > We could start something by using the TLD suffixes of the users' e-mail > addresses, as .DE .CH .FR .CH .AT addresses and many more could used as a rough > indication, in which timezone these user "live" !! !! All of them needs > certainly a time shift tonight. Do not apply, if the users apparently(!) prefer UTC: if TLD = .de .fr .at .ch (and so on) and current-offset <>'00:00' then ... /* apply ad-hoc patch only, if the user most probably has already chosen to use local time */
... use the top level domain of email addresses and current time offset value as a first indication, where the user lives
(In reply to comment #12) > ... use the top level domain of email addresses and current time offset value as > a first indication, where the user lives That's an intriguing idea - note that not all users have an e-mail address set at all, and that many will have .com (e.g. hotmail.com) or even "foreign" addresses. In fact, it seems to me we have several points of information which could be used, if technically feasible and desirable, to guess users' locations, namely: * offset currently chosen (obviously) * national TLD (if present) of e-mail address (if present) * interface language selected, if different from the site's default (e.g. on a multilingual site like meta, or a 2nd-language wiki, users can now select their first language for the interface) ** or, on some wikis, the very fact that they *haven't* selected a different interface (e.g. editors on a Swedish-language wiki, whose timezone is currently consistent with living in Sweden, can reasonably be assumed to be in Sweden). If the available information is a) consistent, and b) provides a pretty strong indication that the user is in a particular region (i.e. we can assume that people on an obscure island that doesn't do DST won't mind all that much being put in the wrong location as long as they can fix it) then we can enter the location into their preferences instead of the bare offset.
(In reply to comment #13) > > ... use the top level domain of email addresses and current time offset value as > > a first indication, where the user lives > > That's an intriguing idea .. In fact, it seems to me we have several points of information which > could be used, if technically feasible and desirable, to guess users' locations, > namely: > * offset currently chosen (obviously) > * national TLD (if present) of e-mail address (if present) > * interface language selected, if different from the site's default (e.g. on a > multilingual site like meta, or a 2nd-language wiki, users can now select their > first language for the interface) .. > If the available information is a) consistent, and b) provides a pretty strong > indication that the user is in a particular region --> then the wikisoftware _could_ propose an automatic change of the user settings - migrating from "Time Offset" to "Time Zone" settings - by sending out one e-mail with the suggested new setting (e.g. Germany-MET/MEST = mid european time and mid european summer time = "Gesetzliche Zeit Deutschland") which the user can accept by clicking. Dear Rowan, thanks for your contribution !
(In reply to comment #14) > --> then the wikisoftware _could_ propose an automatic change of the user > settings - migrating from "Time Offset" to "Time Zone" settings - > by sending out one e-mail with the suggested new setting > (e.g. Germany-MET/MEST = mid european time and mid european summer time = > "Gesetzliche Zeit Deutschland") which the user can accept by clicking. I would be extremely wary of doing this by e-mail, as people have not said that they wish their addresses to be used in this way (which comes rather close to mass-mailing) and might not be pleased at the precedent it sets. It also rules out making suggestions to people with no e-mail entered (e.g. by matching with language preferences, or even offering multiple options based purely on offset). I like the idea of "offering" rather than automatically changing, though - perhaps a message could be displayed on the site itself, similar to (or even just making use of) the "You have new messages" one. For instance, just before the next adjustment (October for E.U. countries) it could appear saying "Your current settings suggest that you are in <location>/one of the following locations; by selecting the appropriate link below, you can enable the software to automatically adjust for 'Daylight Savings Time'/'Summer Time' on the appropriate dates." That way, we could just completely guess from offsets if no other clues were available, and show the message to *every* user; an "Other" link could take them to the appropriate preference screen to select manually. OTOH, people might find even *that* unnecessarily obtrusive, and prefer just to discover the new option when they get round to manually fixing the offset, I'm not sure...
(In reply to comment #15) > I would be extremely wary of doing this by e-mail, as people have not said that > they wish their addresses to be used in this way Yes, you might be right; this is why I wrote "_could_ send a mail" - with the markers. I justed wanted to bring up this idea to trigger new, alternative ideas. Again, thanks. What's missing ? A kind of algorithm. It think, we both could start writing something, don't you think ? Should probably go into the several login code functions and also specialpreferences.php, I guess.
*** Bug 2004 has been marked as a duplicate of this bug. ***
I propose, to solve also the issue of this bugzilla soon: instead of TimeOFFSET, allow users to store a TimeZONE which better reflects relation between servertime, localtime and UTC. Any Windows detects timezone and daylight saving time offset, when it changes twice a year, quite well, why not we in MediaWiki ? Potentially blocking http://bugzilla.wikipedia.org/show_bug.cgi?id=1002 (1.5)
This should not be made to block bug 1002 since this is a non-essential feature request.
Created attachment 517 [details] ad-hoc fix to overwrite user timezone settings - not a solution This first patch is for users running a local wiki, e.g. in an intranet, and who want to set the display time e.g. for page history to their local time. With the patch the time offset is preset (fixed) and cannot be changed by users as long as $wgTimezoneoffsetOverwrite is set and has an value. The current fix allows them (the WikiSysops) to preset a value for the timezone offset, example for Mid European Summer Time: $wgTimezoneoffsetOverwrite = '02:00'; The corresponding user input form is now blinded out, but the offset value is shown - with the additional text " (fixed)".
Created attachment 518 [details] corrected two typos. Ad-hoc fix to simply overwrite user timezone settings - not a solution
I suggest DST and timezone/offset be separate. "Use DST" should be a simple checkbox. It would save a lot of work having to guess which timezones and areas (Arizona/Indiana anyone?) use DST, and would hopefully lead to the checkbox option going live fast. Yes, there would be some logic needed to check for US/EU/Other start and end dates, but less so than as a combined feature.
(In reply to comment #22) > I suggest DST and timezone/offset be separate. "Use DST" should be a simple checkbox. It would save a lot of work having to guess which > timezones and areas (Arizona/Indiana anyone?) use DST, and would hopefully lead to the checkbox option going live fast. Yes, there would be > some logic needed to check for US/EU/Other start and end dates, but less so than as a combined feature. The question is, whether a "daylight saving time" checkbox is sufficient. For example: in the 70s and 80s, Europe and US had different days for changing from/to daylight saving time. And, moreover, what's about countries in the southern hemisphere ? Do they change on the same date as the northern countries, which switch on last Saturday in March and October ? I have my doubts and need more information.
Yes, you would still have to check which general location the user was in. However, establishing start and end dates for what basically amounts to separate continents should be a lot easier than doing so for every country, state or other subnational entity which may or may not use DST. :) The main point is to decouple DST from time zone.
Collecting background information. [3] could be used for a built-in checker (validator) of allowed timezone codes and corresponding offsets Resources: [0] http://en.wikipedia.org/wiki/Daylight_saving_time [1] http://www.netz-tipp.de/kat/Reference/Time/Current_Time/ List of _good_ pointer [2] http://www.worldtimezone.com/ A world map with inserted clocks for every time zone in the world. [3] http://www.worldtimezone.com/wtz-names/timezonenames.html All time zone names and offsets [4] http://www.nmm.ac.uk/site/request/setTemplate:singlecontent/contentTypeA/conWebDoc/contentId/344 Article from Royal Observatory Greenwich on European summer time, daylight saving time.
(In reply to comment #24) > Yes, you would still have to check which general location the user was in. This might be not sufficient, see below > establishing start and end dates for what basically amounts to separate continents should be a > lot easier than doing so for every country, state or other subnational entity which may or may > not use DST. :) > > The main point is to decouple DST from time zone. Yes and no. A single checkbox is not giving enough information, because there might be areas having more than two different offsets, let me cite from DST article on enwiki http://en.wikipedia.org/wiki/Daylight_saving_time "DST commonly begins in the Northern Hemisphere on either the first Sunday in April or the last Sunday in March, and ends on the last Sunday in October. In the Southern Hemisphere, the beginning and ending dates are switched (thus the time difference between, e.g., the United Kingdom and Chile may be three, four, or five hours)." --> "thus the time difference between, e.g., the United Kingdom and Chile may be three, four, or five hours)." "Australia has a mixed implementation of daylight saving time. During winter it has three time zones, but when daylight saving time is in effect, it has five time zones (mostly differing by 30 minutes) ranging from UTC+8 to UTC+11. Although there have been several referenda on the topic, Western Australia, the Northern Territory and Queensland have not adopted the practice. As a result, the tropical regions of the country do not observe daylight saving. Interestingly, during daylight saving time, South Australia observes a time later than Queensland, despite the latter being almost entirely further east. Tasmania starts DST earlier than the rest of the country, usually at the start of October."
So, this bugzilla has now enough information to program 'something'.
Collecting background information, added [5] [3] could be used for a built-in checker (validator) of allowed timezone codes and corresponding offsets Resources: [0] http://en.wikipedia.org/wiki/Daylight_saving_time [1] http://www.netz-tipp.de/kat/Reference/Time/Current_Time/ List of _good_ pointer [2] http://www.worldtimezone.com/ A world map with inserted clocks for every time zone in the world. [3] http://www.worldtimezone.com/wtz-names/timezonenames.html All time zone names and offsets [4] http://www.nmm.ac.uk/site/request/setTemplate:singlecontent/contentTypeA/conWebDoc/contentId/344 Article from Royal Observatory Greenwich on European summer time, daylight saving time. [5] http://www.timeanddate.com/time/ comprehensive information about DST; tables of DST changes date
Collecting background information, added [3a] [3] could be used for a built-in checker (validator) of allowed timezone codes and corresponding offsets Resources: [0] http://en.wikipedia.org/wiki/Daylight_saving_time [1] http://www.netz-tipp.de/kat/Reference/Time/Current_Time/ List of _good_ pointer [2] http://www.worldtimezone.com/ A world map with inserted clocks for every time zone in the world. [3] http://www.worldtimezone.com/wtz-names/timezonenames.html All time zone names and offsets [3a] http://www.worldtimezone.com/daylight.html all DST times and changes [4] http://www.nmm.ac.uk/site/request/setTemplate:singlecontent/contentTypeA/conWebDoc/contentId/344 Article from Royal Observatory Greenwich on European summer time, daylight saving time. [5] http://www.timeanddate.com/time/ comprehensive information about DST; tables of DST changes date
(In reply to comment #29) > [3a] http://www.worldtimezone.com/daylight.html all DST times and changes I just tried to contact the webmasters of this great page. If they deliver me the data in _table_form_, such a table could be straightforward used to generate now and then an option box in user preferences. Users could then select their country (or timezone code) and timeoffsets could be adjusted by the wiki automatically when DST applies or not.
changed title
Sniplet from account management page of http://sourceforge.net/account/ - if you have an account. hundreds of lines deleted: <select NAME="timezone"> <option VALUE="US/Alaska">US/Alaska</option> <option VALUE="US/Aleutian">US/Aleutian</option> <option VALUE="US/Arizona">US/Arizona</option> <option VALUE="US/Central">US/Central</option> <option VALUE="US/Eastern">US/Eastern</option> <option VALUE="US/East-Indiana">US/East-Indiana</option> <option VALUE="Pacific/Fakaofo">Pacific/Fakaofo</option> <option VALUE="Pacific/Fiji">Pacific/Fiji</option> <option VALUE="ROK">ROK</option> <option VALUE="Singapore">Singapore</option> <option VALUE="Turkey">Turkey</option> <option VALUE="UCT">UCT</option> <option VALUE="Universal">Universal</option> <option VALUE="UTC">UTC</option> <option VALUE="WET">WET</option> <option VALUE="Zulu">Zulu</option> </select></td>
See provisionally http://meta.wikimedia.org/wiki/MediaWiki_FAQ#How_do_I_set_the_timezone_for_my_MediaWiki.3F
*** Bug 3305 has been marked as a duplicate of this bug. ***
Comment on attachment 518 [details] corrected two typos. Ad-hoc fix to simply overwrite user timezone settings - not a solution This patch is fully obsolete, because the $wgLocalTZoffset variable serves the same purpose. I simply did not know about that variable, because it is/was not listed in DefaultSettings.php. Attention: currently $wgLocalTZoffset only allows to set non-fractional hour offsets, examples: $wgLocalTZOffset = '+2'; (to display all date/times in a mediawiki with an offset of +2 hours to the servertime, most often UTC.) Further reading in http://bugzilla.wikipedia.org/show_bug.cgi?id=3305 .
one week left to implement this :-((
Is anyone working on a solution/implementation of that ? It's also a long-felt need.
There is an excellent timezone database at http://www.twinsun.com/tz/tz-link.htm that maps geographical locations to timezones. Since we now accept timezones at the config level in these formats (!), it's probably about time we accepted them as a user config. Considering that hundreds of thousands of people have customized time offsets on >1000 MW wikis, it makes sense to leave the existing TZ offset in the UI, and use it only when the timezone setting is not set. Like: Choose a timezone: [America/Montreal ▼] Or specify tz offset: [-4:00]
is there any progress on this bug? Had to change the diff manually again :(
Basically we either have to rely on the operating system's time zone information or PHP's time zone information. The OS might be tricky as: a) Accessing that information will be OS-dependent (finding a list of available zones) b) Presenting that list in a localizable manner may be tricky c) The TZ info might not be reliable -- the United States, New Zealand, and parts of Australia have changed their daylight saving time rules in the last couple of years. Depending on your OS, whether you've applied updates, and even whether those updates are *available*, the OS may have incorrect results. PHP's build-in TZ info has some the same problems, plus it might be out of sync with the OS and is only available in recent versions of PHP. It may be best if some interested party dives into the PHP datetime functions and just codes up something that works on PHP 5.1 and later (or if necessary, 5.2 and later). Then at least it should be self-consistent. :)
All I know is here I am looking at Time zone Server time 05:24 Local time 13:24 Offset¹ ¹The number of hours your local time differs from server time (UTC). and thinking in Unix we can just do TZ=Asia/Taipei just once forever, daylight savings time or not.
*** Bug 13648 has been marked as a duplicate of this bug. ***
Created attachment 5500 [details] A patch to allow timezone selection in user preferences This is a first shot at a patch to allow timezone selection in the user preferences. I took a bit of a different approach than some of the previous comments suggested: I make absolutely no attempt to guess what time zone a user might want, and all existing users will keep their existing offset-based preference until they change it. This is both easiest to code and follows the principle of least surprise. If the current PHP does not contain the new DateTime functions (enabled in 5.2 by default, and 5.1 with a special compilation option), the patch should make no difference to the current operation of MediaWiki; all uses of the DateTime functions are wrapped in function_exists(), with fall-through to the old offset-based code. If these functions are available, the following changes are available. * Currently, the 'timecorrection' user preference may be empty, an integer, or a "+HH:MM" formatted string. The patch adds a fourth option: a [[w:Zoneinfo]] timezone name. * Special:Preferences will contain a dropdown list containing the available timezone specifiers, as returned by timezone_identifiers_list() with the backwards-compatibility options filtered out. There is also an option to use the existing Offset box, for users who haven't yet updated their preference and for users who want to keep using the offset-based system. * Two new system messages are added: 'timezoneselect' contains the label for the new dropdown list, and 'timezoneuseoffset' contains the text for the "use the existing Offset box" option in that dropdown. * $wgLang->userAdjust() will recognize the new possibility for its $tz parameter, and use the DateTime functions to do the timezone correction in that case. I also took the opportunity to fix bug 15980. The patch does not add a configuration variable to disable this new feature, although one could easily enough be added. It should be noted in that case that changing the setting from enabled to disabled would then result in 0 offset being used for all users who had specified a timezone in their prefs. The patch doesn't attempt to allow localization of the Zoneinfo names. If this is desirable, I could try to work that out (I guess using pages like "MediaWiki:Zoneinfo/America/New_York"?). Also, it might be useful to note in the documentation the existence of the pecl timezonedb module, which contains updates to the timezone database used by the DateTime functions.
Functionality seems good! Might want to consider the interface; right now it's a bit unclear how the "timezone" and "offset" parameters interact.... The Offset field should either be hidden entirely or disabled when another timezone is selected, since it won't be used in this case. The "Fill in from browser" which detects the hour offset should either be disabled as well in this case, or should override the "Timezone" back to "Use 'Offset' below" so it'll actually do something. Updating the "Local time" (and maybe the offset!) visibly when an item is selected might be good too, so you don't have to save and go back to the form to confirm you picked the right timezone. Consider also having the default in the drop-down be something like "server default", with an "Other" or "manual offset" option that will be automatically selected if the offset field is filled in manually.
Created attachment 5600 [details] Updated patch based on Brion's comments I had to change the data format to make it work sanely, but I think it's better this way anyway. If someone wants to add another method of specifying date offsets now, it should be pretty easy to add. Changes since the last patch: * There is now an option for "System time offset", which uses $wgLocalTZoffset. * The format of the 'timecorrection' user option, and thus the various $timecorrection parameters used in Language.php, has changed again. The old style (integer, or hour:minute value) is still accepted for backwards compatibility. Other possibilites are now: ** "System|$minDiff", which specifies that $wgLocalTZoffset is to be used. $minDiff is a copy of $wgLocalTZoffset at the time the preference was last set, and is currently ignored. ** "Offset|$minDiff", which specifies a specific difference in minutes. ** "ZoneInfo|$minDiff|$zone", which specifies a specific zoneinfo timezone. $minDiff is the offset in minutes for the specified timezone at the time the preference was last set, and is used as a fallback in case $zone later cannot be loaded. ** Any new method can be added easily enough in the future, as long as it conforms to the general "$tag|$minDiff|$whatever" layout. * The offset field is now disabled unless "Offset" is selected in the dropdown. The "Fill from browser" button changes the dropdown to "Offset" and fills it in. * The local time and offset are now updated as the fields are changed. This is done by storing the UTC time in minutes in a hidden field, and using the "$minDiff" value from the possible timecorrection values. * Another system message has been added, 'timezoneuseserverdefault', which specifies the text of the "Use server default" option in the dropdown. * It looks like the wfTimestamp timestamps are always in UTC; I'm not sure this won't break if that is ever not true. Of course, I'm not sure the old code won't break in that case either. * The dropdown is now displayed even if the PHP timezone functions are not available, to allow the user to select the server default or a specific offset.
Created attachment 5612 [details] Modified patch to fix PST bug, tweak text Looks good! A couple minor tweaks in this version: I noticed that the local time display update wasn't working right when I used the detection button. Problem turned out to be that parseInt() by default attempts to interpret numbers starting with a "0" as octal, thus our zero-padded offsets for 8 or 9 hours off from UTC would fail ("-08" -> 0). Passing base 10 explicitly to parseInt() resolves this. I wouldn't have noticed this bug in the summer, when California time is -07:00... ;) Additionally, the offset was saved incorrectly due to use of "+" in PHP code where the concatenation operator "." is needed. ("+" coerces strings to integers in PHP, so we got "-480" instead of "Offset:-480"... the "-480" was then interpreted as -480 hours when re-loaded.) I also went ahead and changed the text string in the drop-down for the explicit-offset selection to "Other (specify offset)", which seems a little more consistent with the UI to me. Ready to commit unless anyone notices any other issues...
Applied in r44915, whee!
