OMG WTF detailed files BST?

[Local (BenR)]

Hi Mark,

Thanks for your response, very helpful.

Unfortunately I don't know what the filesystem of the volume with the files is 
- this is a client's network, and they set up a VM in the DMZ for me to work 
on, with this network share mounted - but I've no idea what the fileserver is.

The thing that puzzles me is why the Windows Explorer is reporting the mod 
date of these files correctly, while LC isn't.

However, I've now restarted the VM - no change to how Windows Explorer reports 
the dates; and then told it not to adjust for daylight saving time and 
restarted it again: the clock on the machine went back by an hour, but the 
time reported by Windows for the files on the network share didn't change.

I'll see what happens when the job runs overnight, whether one or both these 
things fixes the timestamps that LC gets...

Ben

On 31/03/2017 12:22, Mark Waddingham via use-livecode wrote:
> On 2017-03-31 13:20, Mark Waddingham via use-livecode wrote:
>> Hi Ben,
>>
>> This might be of interest:
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx
>>
>> On 2017-03-31 12:48, Ben Rubinstein via use-livecode wrote:
>>> The standalone, built from LC 6.7.11, is running on a Windows machine
>>> (VM running Windows Server 2008 R2) in London, which has a volume
>>> mounted from a server running an unknown operating system.
>>
>> What is the filesystem of the volume? The above document suggests that
>> FAT stores
>> filetimes in local time and *not* universal time which sounds like it
>> might be the problem...
>
> I just re-read the pertinent paragraph:
>
> The FAT file system records times on disk in local time. GetFileTime retrieves
> cached UTC times from the FAT file system. When it becomes daylight saving
> time, the time retrieved by GetFileTime is off an hour, because the cache is
> not updated. When you restart the computer, the cached time that GetFileTime
> retrieves is correct. FindFirstFile retrieves the local time from the FAT file
> system and converts it to UTC by using the current settings for the time zone
> and daylight saving time. Therefore, if it is daylight saving time,
> FindFirstFile takes daylight saving time into account, even if the file time
> you are converting is in standard time.
>
> Sounds like a restart is needed to ensure that the APIs the engine has to use
> are correct...
>
> Mark.
>