@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.

This still happens as of v6.1.0.1, 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 ... :) ).

Another current example: https://commons.wikimedia.org/wiki/File:Ethiopian_Region_Map_with_Capitals_and_Flags.png

Two more examples of widely-cited, American, sites:

• The date is not retrieved from this "USA Today" article.
• The author is not retrieved from this "Los Angeles Times" article.

@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.

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.

Thanks. I'll head there.

My original report of this bug at enwiki has just passed its sixth birthday.

Or just "Public logs".