Unix timestamp: 1 hour difference?

An mp3 file, on Windows10, shows a date/time of 31-10-2012 11:21.
That is exactly what Mp3tag-file_mod_datetime shows: 31-10-2012 11:21:28.
The unix filestamp = file_mod_datetime_raw = 1351678888.
If I put that number in Excel =(((file_mod_datetime_raw/60)/60)/24)+DATE(1970;1;1)
then I get 41213.43157 , which formats to 31-10-2012 10:21:28,
i.e. exactly 1 hour earlier.

Can someone explain why this difference? Thanks!
PS I am in the Netherlands, it's daylight saving time here. Any connection?

Does this apply only to mp3 files or to other file types like doc, txt, jpeg etc. as well?

I tried another file, a WAV file: 1-9-2018 20:40:53,
with Mp3tag field file_mod_datetime_raw = 1535827253.
That converts to 1-09-2018 18:40:53, two hours difference ?!

And I tried a FLAC : 1-9-2018 20:42:13,
with Mp3tag field file_mod_datetime_raw = 1535827333
That converts to 1-09-2018 18:42:13, also two hours difference.

Tested some more MP3 files: 1-9-2018 20:33:05,
with Mp3tag field file_mod_datetime_raw = 1535826785
That converts to 1-09-2018 18:33:05 , also two hours difference.

Hmm, all of these are actually on a local Windows10 disk. All I find is 2 hours difference.
The earlier example (I tested many) were all on NAS systems, with 1 hour difference.
Is that a clue?

How would I test .doc or .jpg files? They cannot be listed in Mp3tag.

Isn't it that dates are saved in UTC which is basically the GMT plus an offset?
So if you are living in a timezone that has an offset to GMT plus settings like daylight savings time then this adds up to such differences.
Any date is returned by the OS.
So it could be that you have set your various devices to different times, e.g. one "knows" that it uses DST, the other takes the time as absolute value and does not calculate with any offsets.
In total I do not think that this is really an MP3tag matter - Mp3tag is only the messenger.

The modify-time that I see on Win10 and directly on the NAS systems show the same in their respective file-systems.
But maybe you are right, the audio-files could have been copied from system to system, and in this way their time-info got scrambled.

One relevant question: where does Mp3tag get it's information from? Is it just from one source, i.e. the modify-time that is written in the file's header ? (Not audio-tag.)
Or does Mp3tag have different sources for file_mod_datetime and file_mod_datetime_raw ?
I would say if it's just one source, than there must be a computation in Mp3tag, which could be off. If it's two sources, then something could be wrong in the file-info / tag and Mp3tag is just reporting that.

MP3tag uses the OS functions to get the file info.

So then how can file_mod_datetime and file_mod_datetime_raw lead to different outcomes?
Sometimes 1 hour of, sometimes 2 hours off?
What happens on your PC or NAS?

One variable that could figure in this is the conversion from file_mod_datetime_raw to Windows date: there we use the factor DATE(1970;1;1), which is or course no DST. My example of a September date would be in DST. But while 31 Oct is not DST.....

I think it is now time for you to find another utility that verifies your findings.

E.g. does the Windows explorer show anything different than MP3tag?