40 minutes difference between Xojo and Finder time files

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?

:thinking: Christian is an MVP now - maybe you could ask him how MBS does it correctly? :grin:

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. :slight_smile:

I meant Greg :grin:

And I have the complete plugin package. :wink:

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.

I’m sure @Christian_Schmitz will tell them how he does it, not sure if the team will be humble enough to accept or ask for help. He helped them more than once finding Xojo very deep bugs they had no clue before. I even vote to Christian to sign an NDA and some special contract to have access to the Xojo sources to help them in an eventual, non-paid, voluntary fashion.

3 Likes

Clearly this is a bug on (Xojo?) MacOS side:

Note i use DateTime instead of Date since “Date” is deprecated.

Windows DateTime instance (works correctly):
Note: Windows has one bug an that is DateTime.DayOfWeek shows 2 while it should be 1 since the day starts @ monday and the day on the image below is monday:

Windows FolderItem.ModificationDateTime:

Both Date and Time seem to be correct in “Europe/Amsterdam” or GMTOffset 3600

On MacOS, TimeZone “Europe/Amsterdam” GMTOffset 3600:

The MacOS Finder (“Bewerkingsdatum”) 18-01-2021 11:02 (DD-MM-YYYY HH:MM):

The Xojo Code:

The Xojo Debugger shows 18-01-2021 10:21:57 (DD-MM-YYYY HH:MM:SS), this means the correct DateTime - 40 minutes? Xojo shows a DateTime that misses 40 minutes (at least).

]

Note Also on MacOS the DayOfWeek is wrong, on the machine the values are set the same as the windows machine in the previous post. Day starts with “Monday” so day of week (as today is monday) should be 1 NOT 2.

I think that is “as designed”, check DateTime — Xojo documentation

The day of the week as an integer: 1=Sunday, 7=Saturday.

You can open a feature request to make 1=Monday when the locale say the week start in Monday.

Yeah then it’s a bad design, pretty misleading name.

@DerkJ also note that WeekOfYear is 4 for USA and other countries, while is 3 for Germany and other countries but Xojo will only report the USA value.

I’d think it should return what the OS reports.

1 Like

Agree, users set up there regional settings in System Preferences. Apps we make in Xojo should use those settings. How else can you make an app. My apps have users in over 100+ countries.

The mentioned 40 minute difference is Amsterdam only. Worldwide the difference is one big mess. Excusez le mot.

I use my software made with Xojo to change DateTime of files ManageNameExt .
First capture it just read the modification date of the file :


I also show my System preferences, I live in France.
Then I use my application to set the modification date to june 22 14:00:00 :

There is 1 hour and 50 minutes difference, but maybe the 1 hour is my fault because I don’t set daylight as it should or the time offset or something else. I use the new datetimepicker to set my datetime.

I have a button for my test which contains the code above and give the result :



And this is exactly the DateTime when I click the button. I do not have 50 minutes error.

Has anyone tried removing the GMT offset before setting the date time on the file?

Reading ModificationDateTime is not the same as setting it…

Does it correctly set the date time, just displays it incorrectly?

On my screencapture I set it to 14:00:00 and it set it to 15:50 but when I read it again with Xojo it read it 14:00:00

Looks very similar to the problems discussed in folderItem.creationDate can't set timezone