Jul 8 2020
@Jonesey95: That's not surprising, as I don't see any change at all on enwiki in the way it handles the ToI or IT examples I gave in the original discussion there or the USA Today and LA Times examples given here.
May 22 2020
This still happens as of v220.127.116.11, SVN 12353 (2019-09-17 21:16:42). As others have said, we usually lose a LOT of work. The reason is because it happens only after an extended edit session – I'd say over about 15–45 minutes. I'm not sure if the auto-save happens immediately before the upload, or whether the re-processing of the article might over-write it, so I've had to start saving to another text file before attempting to save a longer session, including having to separately save a summary that may have been carefully constructed over than time, and also disappears after the restart. All that, and the recovery of it, of course, is time that can be better spent on edits (or relaxing, or ... :) ).
Mar 19 2020
Another current example: https://commons.wikimedia.org/wiki/File:Ethiopian_Region_Map_with_Capitals_and_Flags.png
Mar 18 2020
Mar 13 2020
Mar 11 2020
Feb 15 2020
Two more examples of widely-cited, American, sites:
Feb 1 2020
@Tacsipacsi The preferences are storing the time zone correctly – it's the use of the time zone in adjusting the UTC timestamps displayed in NavPops that's the problem (see my comment above). I stand corrected (by JJMC89 below) – I didn't realize it was storing the offset, which doesn't make sense, since it's incorrect to just add that offset to any timestamp to get a local time.
Jan 20 2020
Dec 22 2019
I believe I looked at the code at some point. WIth my limited knowledge of whatever language it was written in, I think I determined that the problem is that it is (incorrectly) determining the offset based on the current time and then applying that offset to all timestamps, regardless of when they are.
Nov 18 2019
Thanks. I'll head there.
Nov 8 2019
My original report of this bug at enwiki has just passed its sixth birthday.
Or just "Public logs".