Page MenuHomePhabricator

"time offset from UTC" timezone option in Special:Preferences doesn't work with negative offsets with minutes
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT


Steps to replicate the issue (include links if applicable):

What happens?:
The field reads "-03:30", and everything else behaves as such.

What should have happened instead?:
It should be "-02:30" as I previously set.

Other information (browser name/version, screenshots, etc.):
I noticed this while working on things related to T309629, but the bug predates that work. The reason is very simple, several places use this logic to build the offset string:

sprintf( '%+03d:%02d', floor( $offset / 60 ), abs( $offset ) % 60 )

this works well with positive offsets and negative offsets rounded to the hour. However, if the offset is something like "-150", $offset / 60 is negative, and floor() returns the closest integer at the left, in this case -3 and not -2.

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptSep 23 2022, 10:00 PM

Change 834617 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/core@master] Fix logic for formatting negative timezone offsets

Daimona set the point value for this task to 1.

A historical note: apparently this bug was introduced in 2009, when preferences themselves were introduced in MW core. I guess nobody uses negative offsets not rounded to the hour :)

Change 834617 merged by jenkins-bot:

[mediawiki/core@master] Fix logic for formatting negative timezone offsets

@Daimona the offset for -2:30 is working correctly now, but I am seeing a remaining bug for this on en betacluster. check out the gif below for testing with -12:30 offset. It sets it as as an offset of -12:00 instead of -12:30. Anything beyond an offset of -12:00 will displayed as -12:00. (for example, input of -23:00 will also default to -12:00)

Screen Recording 2022-10-07 at 2.30.10 PM.gif (1ร—2 px, 3 MB)

The limit at -12:00 is intentional (there is also a limit at +14:00), in accordance with the time zones used in practice in the world ( This should probably be treated as an error though, rather than the input being silently modified. (The same thing currently happens with completely invalid input like "asd", and should probably also be changed.)

Yeah, what @matmarex said. I've created T320296 for it, but I don't think we need to fix it. The bug reported in this task could happen with real-world data, but I don't think anyone would enter offsets < -12 or > 14 as part of normal usage.

ifried added a subscriber: ifried.

I tested this via Special:Preferences#mw-prefsection-rendering-timeoffset on the beta cluster, and it is working as expected. I am marking this as Done.