OMG WTF detailed files BST?

[Ben Rubinstein]

I have an interesting situation. The detailed files is reporting a LIE in 
modification dates.

I have a standalone app which outputs a report including the modification date 
of a bunch of files (and subsequently interprets and acts on it).

On Monday, a BAD THING happened at my client's side. On investigation it 
turned out to be because on Sunday night my software (which runs every night) 
decided that a very large number of files had been modified since the last 
time it checked, and took some actions in response.

The files hadn't changed, but the clocks in the UK have - they went forward 
one hour on Sunday morning, because of British Summer Time (BST).

However, a file that was last modified, for example, at 8:40am on July 27, 
2015 should not therefore be reported as having been modified at 9:40am on 
July 27, 2015. But that's essentially what happened.

The app dumps the mod date from the "detailed files" directly to file, i.e. a 
value for the seconds since 1 Jan 1970. This isn't about how the time was 
displayed for humans, but a direct comparison of the value returned by 
'detailed files': on Sunday night, each value had increased by 3600.

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.

Essentially the same software has been running every night for several years 
on a Windows VM in America, and does not appear to have encountered this issue 
twice a year. I initially blamed STUPID WINDOWS for this screw-up, and guessed 
it might be some issue to do with the respective file-servers, and an 
operating system somewhere second-guessing the other one and messing up by 
adjusting redundantly for time-zone issues.

However, when I actually logged into the machine and used Windows Explorer to 
view the files on the mounted drive, it shows the example file as modified at 
8:40am on that day. Which points the finger at LiveCode (and makes the fact 
that the US install hasn't encountered this issue stranger).

Is there some error in the code by which LiveCode converts the file timestamp 
that it gets from Windows, to the unix style seconds-since-1/1/1970 - taking 
account of timezones and daylight saving times when it shouldn't?  Is there a 
property somewhere - in LiveCode, or on an Windows server - which can be set 
to avoid this issue?

Ben