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

rowan.collins wrote:

[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.

rowan.collins wrote:

(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

rowan.collins wrote:

(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 !

rowan.collins wrote:

(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)

avarab wrote:

This should not be made to block bug 1002 since this is a non-essential feature
request.

Created attachment 517
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)".

attachment timezonecorrection.diff ignored as obsolete

Created attachment 518
corrected two typos. Ad-hoc fix to simply overwrite user timezone settings - not a solution

attachment timezonecorrection.diff ignored as obsolete

magnusrk+wiki wrote:

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.

magnusrk+wiki wrote:

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

moz wrote:

*** Bug 3305 has been marked as a duplicate of this bug. ***

Comment on attachment 518
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.

evan wrote:

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
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.

attachment diff ignored as obsolete

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
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.

attachment x.diff ignored as obsolete

Created attachment 5612
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...

Attached:

Applied in r44915, whee!