Last modified: 2008-12-22 21:55:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2505, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 505 - Specify timezones by location, to allow automatic adjustments of timeoffset and daylight saving time (DST)
Specify timezones by location, to allow automatic adjustments of timeoffset a...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Automa...
: patch
: 2004 3305 13648 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-16 07:21 UTC by T. Gries
Modified: 2008-12-22 21:55 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
ad-hoc fix to overwrite user timezone settings - not a solution (3.76 KB, patch)
2005-05-10 23:48 UTC, T. Gries
Details
corrected two typos. Ad-hoc fix to simply overwrite user timezone settings - not a solution (3.76 KB, patch)
2005-05-11 00:44 UTC, T. Gries
Details
A patch to allow timezone selection in user preferences (6.42 KB, patch)
2008-11-03 05:46 UTC, Brad Jorsch
Details
Updated patch based on Brion's comments (14.15 KB, patch)
2008-12-20 15:16 UTC, Brad Jorsch
Details
Modified patch to fix PST bug, tweak text (14.17 KB, patch)
2008-12-22 21:31 UTC, Brion Vibber
Details

Description T. Gries 2004-09-16 07:21:10 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.
Comment 1 Brion Vibber 2004-09-16 07:23:37 UTC
I fail to see what this has to do with single-login. Pruned unrelated items from summary.
Comment 2 T. Gries 2004-09-16 16:27:22 UTC
Changed pointer to page
http://meta.wikimedia.org/wiki/Automatic_timezone_selection . Brion: you are
right, I agree. Tom
Comment 3 T. Gries 2004-11-01 01:34:03 UTC
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.
Comment 4 T. Gries 2004-11-08 22:14:05 UTC
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.
Comment 5 T. Gries 2005-02-28 07:32:53 UTC
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
Comment 6 Rowan Collins [IMSoP] 2005-02-28 19:45:38 UTC
[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... :)
Comment 7 T. Gries 2005-03-18 01:45:16 UTC
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.
Comment 8 Rowan Collins [IMSoP] 2005-03-18 19:57:45 UTC
(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.
Comment 9 T. Gries 2005-03-18 23:24:06 UTC
(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
Comment 10 T. Gries 2005-03-26 08:26:42 UTC
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.

Comment 11 T. Gries 2005-03-26 08:59:02 UTC
(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 */
Comment 12 T. Gries 2005-03-26 09:02:35 UTC
... use the top level domain of email addresses and current time offset value as
a first indication, where the user lives
Comment 13 Rowan Collins [IMSoP] 2005-03-30 14:39:54 UTC
(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.
Comment 14 T. Gries 2005-03-30 20:42:06 UTC
(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 !
Comment 15 Rowan Collins [IMSoP] 2005-03-30 23:20:13 UTC
(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...
Comment 16 T. Gries 2005-03-30 23:28:06 UTC
(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.
Comment 17 Brion Vibber 2005-04-29 00:39:26 UTC
*** Bug 2004 has been marked as a duplicate of this bug. ***
Comment 18 T. Gries 2005-05-08 19:55:45 UTC
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)
Comment 19 Ævar Arnfjörð Bjarmason 2005-05-08 20:01:54 UTC
This should not be made to block bug 1002 since this is a non-essential feature
request.
Comment 20 T. Gries 2005-05-10 23:48:02 UTC
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)".
Comment 21 T. Gries 2005-05-11 00:44:49 UTC
Created attachment 518 [details]
corrected two typos. Ad-hoc fix to simply overwrite user timezone settings - not a solution
Comment 22 Dashiva 2005-06-04 00:16:56 UTC
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.
Comment 23 T. Gries 2005-07-05 05:58:26 UTC
(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.
Comment 24 Dashiva 2005-07-05 18:45:50 UTC
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.
Comment 25 T. Gries 2005-07-05 19:43:14 UTC
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.
Comment 26 T. Gries 2005-07-05 19:54:07 UTC
(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."

Comment 27 T. Gries 2005-07-05 20:02:05 UTC
So, this bugzilla has now enough information to program 'something'.

Comment 28 T. Gries 2005-07-05 20:40:32 UTC
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


Comment 29 T. Gries 2005-07-09 19:32:28 UTC
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
Comment 30 T. Gries 2005-07-09 19:39:51 UTC
(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.
Comment 31 T. Gries 2005-07-09 19:41:10 UTC
changed title
Comment 32 T. Gries 2005-07-10 15:08:00 UTC
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>

Comment 34 Arthur 2005-08-30 09:01:22 UTC
*** Bug 3305 has been marked as a duplicate of this bug. ***
Comment 35 T. Gries 2005-08-30 16:45:29 UTC
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 .
Comment 36 T. Gries 2005-10-23 20:31:44 UTC
one week left to implement this :-((
Comment 37 T. Gries 2006-02-15 18:31:32 UTC
Is anyone working on a solution/implementation of that ? It's also a long-felt need.
Comment 38 Evan Prodromou 2006-07-06 02:38:10 UTC
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]

Comment 39 Carl Fürstenberg 2007-10-28 16:40:28 UTC
is there any progress on this bug? Had to change the diff manually again :( 
Comment 40 Brion Vibber 2007-11-30 21:31:16 UTC
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. :)
Comment 41 Dan Jacobson 2007-12-20 05:34:51 UTC
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.
Comment 42 Brion Vibber 2008-04-09 00:13:16 UTC
*** Bug 13648 has been marked as a duplicate of this bug. ***
Comment 43 Brad Jorsch 2008-11-03 05:46:31 UTC
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.
Comment 44 Brion Vibber 2008-12-19 00:06:24 UTC
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.
Comment 45 Brad Jorsch 2008-12-20 15:16:32 UTC
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.
Comment 46 Brion Vibber 2008-12-22 21:31:05 UTC
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...
Comment 47 Brion Vibber 2008-12-22 21:55:29 UTC
Applied in r44915, whee!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links