i was just in the middle of setting up my media library in foobar with playback statistics by creating an action to write the file creation date %_file_create_datetime% to %added%, so i can import it in foobar. thats when i noticed something odd: since i force-sorted my autoplaylists by date-added and the date-added was now the date-created, the files kept moving further and further down everytime i changed a tag. upon looking closer i found mp3tag was changing the file creation date by +1 hour each time i saved the file!
the weird thing is, among roughly 10 files i tested (with various attributes) there were 2 files that were not affected by this. i have tested for length, bitrate, year (tag and filestamp), no tags, no cover, id3-version, renaming the file itself, different directory, rebooting, deleting mp3tag config - until i decided to just reinstall v2.77 and thats when the problem stopped. these were all mp3s by the way.
after i found the problem i decided to test for system time and whether my time zone has something to do with this, this is where it gets weird again: so apparently this bug only occurs between utc -2 and utc +3. so -1, 0, +1 and +2. curiously, it always moves 1 hour forward. and again, the same 2 files were completely immune to this.
anyway, i think this is important to address as fast as possible, some people might lose valuable information from this bug!! i almost wrecked an entire years worth of files if i hadnt tested it first.
bug occurs on v2.81 and v2.81a
EDIT: i forgot to mention, i always use the option “preserve file modification time”. so when i turned that off, it also stopped changing the creation date - but then of course it changes the modification date … so i had to test further because for me thats not an option.