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?


use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to