The issue is solely how MP3Tag renders the file modification time, regardless of whether the tags have ever been modified by MP3Tag. The issue has nothing to do with the MP3Tag option for preserving the original file modification time when changing tags. (I mostly use MP3Tag to retrieve existing file and tag information and almost never edit tags.)
On my system, Windows 7, the issue is present in both the file properties dialog and in the variable %_file_mod_datetime%.
The issue is present only with files whose last modification date was in the alternate time regime, that is, when displaying, during Daylight Savings Time, files whose last modification time occurred during Standard Time, or displaying, during Standard Time, files whose last modification occurred during Standard Time.
I have a folder of MP3 files that I burned from the CD “The Wonderful World of Louis Armstrong” on January 2, 2013. Windows Explorer shows the modified times beginning at 5:27 p.m. If I obtain a folder listing via PowerShell (a simplified version of the command appears below), the LastWriteTime agrees with the times displayed in Explorer; the UTC times begin at 10:27 p.m. That looks correct as I am in the Eastern Time Zone in the United States, which, in January, is under Standard Time and is UTC+5.
Get-Childitem | Select Name, Directory, LastWriteTime, LastWriteTimeUTC, Mode, Length
Now that it is July 2015, my computer is set to Eastern Daylight Savings Time, or UTC+4.
When I look at the same folder with MP3Tag, both the file properties and the variable show the modified times starting at 6:27 p.m. I suspect that MP3Tag is converting the NTFS time of UTC 10:27 p.m. using my current UTC offset of 4, instead of converting it based on the UTC offset of 5 that was in effect in January, when the files were modified.
I will note that other applications also demonstrate this flaw (if it is a flaw). TotalRecorder and Foobar’s file properties both also give the modification times for these files starting at 6:27 p.m. (I can't find a modification time among file properties for Media Player, Winamp, or VLC.)
My programming is generally limited to VBA, and if I use available VBA procedures (FileSystemObject.FileDateTime, or FileScriptingObjects’s file object.DastLastModified) (independently from MP3Tag, in my own Microsoft Access database), I get the same file modification times as MP3Tag. However, if I use Windows APIs to retrieve the modification times and convert them to “specific” time (using SystemTimeToTzSpecificLocalTime) instead of to “local” time, the modification times match those displayed in Windows Explorer, beginning at 5:27 p.m.