Try this code on a Mac, and on a system where the Time Zone is not GMT (London):
dim f as FolderItem = new FolderItem ("/System", FolderItem.PathModes.Native)
dim d as Date = f.ModificationDate
Compare the time shown with the time the Finder shows.
When I try this in the +1:00 time zone (Berlin), then the Xojo time is off by minus one hour compared to what the Finder shows.
To me, this seems wrong.
Happens in version 2019r3.2 and 2021r3.1, so it’s been like this for at least two years, without anyone correcting this. I guess this is intentional, then.
However, with older Real Studio (2012) versions, both Finder and the program show the same time, as I’d expect.
Can someone explain to me why Xojo doesn’t show the same time? How is one supposed to fix that?
Trying the code now.
Just a wild guess. It’s not daylight savings time related is it?
Result matches for me:
Ah, sorry, Just noticed you said NOT GMT.
I know it is the wrong time of the year for DST, but I also know that Europe is getting rid of the concept. I don’t know which way that Germany decided to stick with?
The bug report for that says it was fixed 2 years ago in Xojo 2020r1.
Maybe fixed in .ModificationDateTime only?
I guess the current version does not contain such bug, I can’t test right now as I’m on Windows.
The testing machine must be set as in a locale in a date with daylight savings going on.
I have written a comprehensive bug report that shows the issue quite clearly and instructs the tester what to do if it doesn’t surface:
And yes, as AlbertoD suggests, it appears that the bug was fixed in the newer ModificationDateTime but not in the older ModificationDate.
And Rick, you guessed wrong
Is that a deprecated property? I wouldn’t count on a fix, if so.
Well, only because users shouldn’t use the deprecated one any more in NEW projects, they should certainly be able to rely on an OLD function to still work. Otherwise, that would mean that you can never rely on your older projects to still run correctly (which sometimes even happens, but that should be considered a regression and be fixed ASAP).
AFAICS I think I guessed right. ModificationDateTime as I pointed here seems fixed.
But yes, fixing also the deprecated ModificationDate, while existing, should be done to avoid problems.
I’m not sure they care anymore. I recently discovered that property shadowing of the v1 API BackColor property no longer works which makes it impossible to run existing projects that rely on it.
Where do you see property shadowing in this case? The have different names, both the accessors and the types (Date vs. DateTime).
Apologies for the confusion. I was just highlighting that they don’t seem interested in fixing other v1 API stuff so, in my opinion, there is little chance that this will be addressed.
If the policy is really “don’t fix broken past” when a substitute new feature should be used instead, “the solution” when finding a deprecated broken feature bringing instability to the language would be an early removal of the deprecated broken one and asking people to update their code using the modern one, not keeping it around spreading problems.
The problem here is that Xojo broke something that worked since the beginning until they added the new function. This is different from something that never worked and they introduced a new method to solve the problem.
So, programs that worked fine in pre-2019 versions suddenly break, and you don’t even get a warning about it. It took us a while, with out program suddenly misbehaving in weird ways, until we found this newly introduced bug.
But who am I telling this. Xojo won’t listen to reason, they made that already clear in the bug report.