On my system it clearly shows in the finder that the file was created 40 minutes ago (even when created in visual studio code or text editor).
Agreed. This stuff should be rock solid. Maybe it is a side effect of 59781which was fixed in 2021r1. Do you have a version of Xojo before API 2 to see if it works correctly there?
I only mentioned MBS as if you need a solution today it might be your only hope.
Filed the issue as a bug #63332.
Funny you could not reproduce it bug, the user of my rename app who came up with it was from Germany too.
edit: no sorry, makes sense.
ps. time and computers have a troublesome relationship. Still like the millennium slogan: " It is gonna cost you big time. But at least you will have nothing."
The MBS plugin does it’s job correctly:
MessageBox f.ModificationDateTimeMBS.ToString(Locale.Current)
Shows the correct date/time
But:
MessageBox f.ModificationDateTime.ToString(Locale.Current)
is wrong, 40 minutes too low for some reason. While the SecondsFrom1970 seems to be the correct epoch. So the hour, minute and second properties are wong. But the SecondsFrom1970 seems to be good. Perhaps xojo’s calculations are off by -40 minutes ?
Xojo error is off n minutes depending on timezone.
1 Like
Crazy question:
How many times there is from Greenwich to Amsterdam ?
40 minutes ?
I do not think so, it certainly is a little above 10 minutes only. 
GMT difference = 3600 seconds
Funny stuff: Amsterdam and Berlin have the same timezone. Amsterdam gives a 40 minute error. Berlin doesn’t.
2 Likes
OK, weekend. Although I am not amused with the time bug I did some research on older versions. Works great on version 5.5.5 on the PowerBook G3 PQD 300 
1 Like
Have you filed a Feedback case? If not, do it.
Did file a bug report. Appears the bug is known for a long time and still open.
Oh. Now I see it. <https://xojo.com/issue/63332> Closed because <https://xojo.com/issue/62540> is already known.
I’m in France (TimeZone Paris, France) and I have approximatively 40 minutes too.
New DateTime has many bugs. I already reported a MemoryLeak when using new ModificationDateTime and CreationDateTime .
I reported another problem, when the you read a ModificationDateTime which shouldn’t exists it crash. When we change hour, we jump from 2 o’clock directly to 3 o’clock. Then, if the file has the date when we change hour and its time is 2 o’clock and 10 minutes it supposed to be impossible, and Xojo crash. But is, if a file come from a country where they don’t change hour.
I’m curious. On machines where it fails, could you tell us what the value of
TimeZone.Current.Abbreviation and TimeZone.Current.SecondsFromGMT are? And what your GMT offset actually is?
Christian is an MVP now - maybe you could ask him how MBS does it correctly? 
TimeZone.Current.Abbreviation: Europe/Amsterdam (correct)
TimeZone.Current.SecondsFromGMT: 3600 (correct)
File created: 40 minutes off.
He won’t tell. Buy the complete plugin package.
I meant Greg
And I have the complete plugin package.
Europe/Amsterdam or Seconds offset from gmt 3600
Actual seconds offset is -40 minutes (40 minites lower is shown, equals 2400 seconds =) 1200 seconds from gmt. Which is wrong.