A bug reported a few years ago as fixed - is still there.
The problem now is that setting the creationdatetime of a folder results in a date that is 430 seconds (just over 7 minutes) out.
I have created a new bug report bug report
A bug reported a few years ago as fixed - is still there.
The problem now is that setting the creationdatetime of a folder results in a date that is 430 seconds (just over 7 minutes) out.
I have created a new bug report bug report
Looks like a recurrent regression. Xojo should include tests with asserts to alert them of possible future fails, again, needing fixes redone.
I’m sure Robin will ask:
use an API2 datetime class instead of an API1 date class to store the dates
and it should work fine…
.DateTime is API 2.0…
yes and if you use a date class with these folderitem properties, you get wrong results.
I don’t say this bug doesn’t need a fix, but as it is an api1 bug in an api 2 world, it will never be corrected…
No problems here (added info to the ticket). That is why a sample is suggested:
Edit: no problems with the new sample code either (I guess is a macOS update that is causing the problem)
I guess this only happens with macOS 14.x ?
In the past some bugs needed specific combinations of factors, like some only showing up in specific locales during Daylight Saving Time (DST) periods. So, one guy could present a problem, and another one with the exact same setup (in a different region) not. So more checks may be needed.