The user preferences code that handles timezones (i.e., the "timecorrection" setting) and the code in Language that reads the preference are quite old; they went through several incomplete refactorings, and in general there's an embarrassing amount of tech debt. These are some issues I spotted while looking at that code over the last month or so:

• Some places parse the value of the preference without using UserTimeCorrection, thus duplicating a lot of code. The only remaining place as of Nov 3 2022 should be Language::userAdjust, done in r846996.
• The format of UserTimeCorrection could be simplified, as noted in T125189#8337511:
  • The offset can be omitted in "System"
  • The offset can also be removed from "ZoneInfo"
• UserTimeCorrection only stores a DateTimeZone object for geographical time zones, but not for offsets. I can't really understand why, since offsets are supported by DateTimeZone, so UserTimeCorrection could simply use that consistently.
• The values in the user_properties table can be absolute garbage, presumably because the field didn't have any validation, see T125189. Sigh.
• The timecorrection value stored in the DB can also be an integer (=offset in hours) or a plain offset ("02:00"), without the UserTimeCorrection "wrapper". This format was used years ago and is now only supported for BC. It should be removed from the DB as well. T125189.
• Language::userDate, ::userTime, ::userTimeAndDate, and related methods in Language do not correctly document the timecorrection parameter. They mostly only say int: value of time correction in minutes
  • These methods should generally be refactored, use DI etc., but I guess this might be done as part of a larger refactoring of Language in the future?
• I'm actually even wondering if we should use UserTimeCorrection at all, once the migration above are complete and the BC code is removed. I think it would be possible to replace it with DateTimeZone, the main differences being (AFAICS) that DateTimeZone clamps the offset between -99:59 and +99:59 instead of -12 and +14, and that it doesn't support "System" (but maybe that could be represented with NULL). Also, DateTimeZone is stricter with offsets and actually checks the number of digits, so it won't accept nonstandard things like "+0:555" that are currently accepted by UserTimeCorrection.

There might be more issues that I've forgotten, in which case I'll add them to the task description.