Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
There might be slight behaviour differences, particularly in case of
offsets that are > 14 or < -12, but I don't think it's really worth
special-casing that, since other parts of the code already limits
offsets to values in that interval.
Also fix a bug in UserTimeCorrection where ctype_digit wouldn't
recognize negative offsets specified only as an integer.
Also add a lot of tests for userAdjust, actually testing the parsing
logic, and not just the fallback to the local offset (which is what
**all** the previous test cases were doing). Ideally, this test would be
a unit test and be moved elsewhere, but I don't think it's worth doing
that now, since I assume the Language class will be refactored anyway at
some point.
Finally, use DateTime::modify instead of mktime. It's more readable, it
works the same, but is much more compact. It also means we don't have to
suppress any errors (which I think was already unnecessary, but still).
Bug: T322352
Change-Id: Ie0ccdb0c16aaa6ac888ca1e13008a8b214ac8994
When the time offset was specified as e.g. 'Offset|120' instead of
e.g. '+02:00' (which is possible using the action=options API),
validation of the range was skipped.
Change-Id: Ieb40f0277d3d3705e65eae398afeee1d24e7ef92
As described on the task, floor() returns the closest integer to the
left, and so it's not the right choice in this case for negative
offsets.
Put the logic in a static method of the UserTimeCorrection class so that
it can be reused elsewhere without making the previous mistake, and add
tests for it.
Also update a comment in UserTimeCorrection, as a follow-up to
I99a00dff7e3319ce45883191daee16bec1ed68ba.
Bug: T318455
Change-Id: I9acc8fa278d5a58a1d56c28c9e8b3f9093f8add9
This patch simplifies and fixes a few issues in code related to the
'timecorrection' user setting:
- Always re-apply UserTimeCorrection normalization to the preference
value, although it should be already normalized
- Avoid duplicating code from UserTimeCorrection, both for the
pipe-splitting and the offset computation/fallback
- Use better variable names
- Inject an ITextFormatter for generating the dropdown options, instead
of a ContextSource (ew) or a Language, removing calls to wfMessage as
well. Note that the ITextFormatter is not injected into the
preferences factory because the eventual goal is to move the code to a
new HTMLFormField class.
- In TimezoneFilter, remove a redundant check: the value comes from the
form, and the option for using the system time is always "System|XXX",
never just "System". This seems to have been introduced in
I2cadac00e46dff2bc7d81ac2f294ea2ae4e72f47; the previous code was only
comparing $data[0], and not $tz. Change the test accordingly and add a
test case.
- Add missing star to docblocks in UserTimeCorrection, as well as a
missing int cast.
- Fix typo and other style issues in UserTimeCorrectionTest
- Bonus: add missing docblock star in HTMLApiField
Bug: T309629
Change-Id: Iab35eb17259826429e4b6bc1ba7385ab57884e98
There is a common and reasonable need for longer lines in tests.
The nudge for shorter lines doesn't seem valuable here. The natural
breaks will likely still fall in 80-100 given the enforced practice
for non-test code, e.g. whether through habit, or 80-100 column markers
in text editors, or the finite width of diff and code review
interfaces.
Change-Id: I879479e13551789a67624ce66f0946d2f185e6ee
The parsing of the timecorrection useroption was split over multiple
classes. Combine into a single class and add some testcases.
Change-Id: I2cadac00e46dff2bc7d81ac2f294ea2ae4e72f47
