This is not a Hollywood bug, but a design flaw by Microsoft.
NTFS stores the file date in UTC. But because Windows still works internally in local time (instead of doing everything in UTC and only converting it to local time for display), there is a conflict when switching from CEST to CET (UTC 00:30 would be CEST 02:30 and UTC 01:30 would be CET 02:30). Microsoft resolves this conflict by always converting the date and time of a file to the current daylight saving time or standard time. The incorrect display is therefore intentional.
You can check this by viewing the file date on the cmd command line with “dir”. But Powershell converts in the same way as Explorer, so it shows the modified time.
I just checked in a cmd window and in an explorer window and to my amazement they actually do give different dates for the test file.
Is there some kind of work-around then? Because otherwise I'll think of something else for my purposes because I consider this way too confusing and unreliable.
Flinx wrote: ↑Sat Oct 11, 2025 1:55 pm
This is not a Hollywood bug, but a design flaw by Microsoft.
Thanks for defending Hollywood but I'm afraid I've to admit that it is a bug in Hollywood. Of course you're right about this inconsistency within Windows but of course this shouldn't affect Hollywood, i.e. if you set the date as "01-Jan-2000 00:00:00" using SetFileAttributes() you should get the same date back when using GetFileAttributes(). So that's fixed now.
- Fix [Windows]: Setting file date didn't take any potential daylight saving time setting in the local timezone into account
Btw, the bug will be gone for 01-Jan-2000 00:00:00 starting next Sunday because that's the time Europe drops daylight saving time which means all dates within the range of dates with no daylight saving time will be correct but then of course dates that have daylight saving time will be wrong, e.g. 01-Jun-2000 00:00:00