[Done] GetFileDate() and UTC
Posted: Mon Apr 15, 2024 5:24 pm
Hi,
I've been trying to move all my stuff over to 6.10, and part of that means doing away with separate libraries for things that can now be done natively. Previously I had a dedicated function for getting the UTC timestamp of a file using windows API calls (based on the date64 library). In 610, we now have UTC dates, and although there is no GetFileDateUTC(), I assumed I could use plain GetFileDate() to get the timestamp in my current local time, and then call ConvertDate() to convert that to UTC.
I'm in the UK, and daylight savings is in effect, so for practical purposes my local timezone is UTC+1, and converting local to UTC means subtracting an hour.
But, this does not seem to work as I would expect. For the file I was looking at, these both return the same value
After a bit of poking around with different files, this seems to be because the timestamp of the file is from a time when daylight savings was not in effect. i.e. the above code returns the same value, or different values, depending on the timestamp of the file you choose.
This is a) not how I would have expected this to work, and b) not how the old date64 library did things, which I think means it differs from Windows own idea of what the UTC timestamp of the file is.
If my current timezone is UTC+1, then I would expect ConvertDate() to always result in a 1hr adjustment, as so long as daylight savings is in effect there is always a 1 hour difference between my local time and UTC, and if I want the UTC value of something that is being presented in local time, that correction needs to be made.
Am I doing something wrong here, or misunderstanding how this is meant to work?
Either way, is there a native 610 way to get the UTC timestamp of a file that agrees with the value you get if you go direct to the win32 API? (I.e. I found this issue because the new code was giving different values to the old code, and I need them to agree...)
(This is all on Windows, PB 610 x64, same in ASM and C backends)
I've been trying to move all my stuff over to 6.10, and part of that means doing away with separate libraries for things that can now be done natively. Previously I had a dedicated function for getting the UTC timestamp of a file using windows API calls (based on the date64 library). In 610, we now have UTC dates, and although there is no GetFileDateUTC(), I assumed I could use plain GetFileDate() to get the timestamp in my current local time, and then call ConvertDate() to convert that to UTC.
I'm in the UK, and daylight savings is in effect, so for practical purposes my local timezone is UTC+1, and converting local to UTC means subtracting an hour.
But, this does not seem to work as I would expect. For the file I was looking at, these both return the same value
Code: Select all
Debug GetFileDate(file$, #PB_Date_Modified)
Debug ConvertDate(GetFileDate(file$, #PB_Date_Modified), #PB_Date_UTC)
This is a) not how I would have expected this to work, and b) not how the old date64 library did things, which I think means it differs from Windows own idea of what the UTC timestamp of the file is.
If my current timezone is UTC+1, then I would expect ConvertDate() to always result in a 1hr adjustment, as so long as daylight savings is in effect there is always a 1 hour difference between my local time and UTC, and if I want the UTC value of something that is being presented in local time, that correction needs to be made.
Am I doing something wrong here, or misunderstanding how this is meant to work?
Either way, is there a native 610 way to get the UTC timestamp of a file that agrees with the value you get if you go direct to the win32 API? (I.e. I found this issue because the new code was giving different values to the old code, and I need them to agree...)
(This is all on Windows, PB 610 x64, same in ASM and C backends)