Timezone-related code in MW has been dealing with this polymorphic values for enough time now, I would say, and it should really be cleaned up. According to the doc comment of UserTimeCorrection::parse(), the possible formats are:

• System
• System|60
• Offset|60
• ZoneInfo|60|Europe/Amsterdam
• 16:00
• 10

On top of that, there might be complete garbage as noted in the task description.

However, before tackling this, I would like to clean up timezone-related code a bit more, and see if it's possible to simplify the "new" formats a bit. I'm working on it.

So, I think the following simplifications would be possible:

• Stop putting the offset in the "System" type (it's already ignored)
• Stop putting the offset in the "ZoneInfo" type: AFAICS, it's always recomputed because the value changes with DST, so there's no point in storing it

The first thing to do would be to update UserTimeCorrection and its callers so that nothing uses the old values anymore. Care should be taken when migrating callers. For instance, there might be code stringifying the time correction without using UserTimeCorrection (like Language.php, fixed in r846996, see search). Then the timezone input field should be updated (the JS logic as well).

Once all that is done, writing the script should be easy enough -- just read batches of user_properties rows for the 'timecorrection' property, run the value through UserTimeCorrection, and store the toString().

Eventually, only the following formats should be valid:

• System
• Offset|123
• ZoneInfo|Europe/Amsterdam

Stop putting the offset in the "System" type (it's already ignored)

The offset should still be available for JavaScript to use, even if not stored in the db. Please note that a number of gadgets and scripts, and even extension-loaded JavaScript rely on mw.user.options.get('timecorection') returning a pipe-separated string in which the second value is the offset.