It also means that when you copy a file from Linux (which tracks meta times accurately to 1/100 of a second) to Windows, the time is rounded up or down accordingly. The oddness that ensures is that when you look at the Windows file copy it'll (sometimes) show a one second difference as compared to the Linux copy. (It all depends on rounding.)
My gut reaction was to just divide the times by 100 and remove the two least significant digits from play, but that lowers precision and doesn't quite guarantee that you'll avoid the problem entirely. (Imagine your Unix modified time is 1699999999, in Windows this will become 1700000000 -- oh the imprecision!)
When you get the modified time of a Linux file (say through a Samba share) it'll invariably have two digits to the right of the decimal place. (At least when doing so via something like Python, not from a Windows property box.) If you convert it to an inegert to remove these the number will be rounded up or down accordingly. Instead I decided to do something like the following:
- Round down (regardless of the two digits to the right of the decimal)
- Convert to integer
- Check if the number is even (modulus 2)
- If it is even, add 1
So going back to our initial example, say your Linux file comes back with a modified time of 1699999999.42:
- 1699999999.00 (Round down)
- 1699999999 (Convert to int)
- Not even (1699999999 % 2 = 1)
- 1700000000 (Add one)
- Voila, it matches the new Windows copy
(Yes, the conversion to an integer isn't really necessary, but we're dealing with whole numbers already anyway, so why not?)
The above steps ensure that you'll end up with a Windows compatible view of the modified time. So what does this look like in Python code? See below:
mtime = int(math.floor(os.path.getmtime(fileLocation)))
if mtime%2:
mtime += 1 
