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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
