Added a comment

1 files changed, 26 insertions, 0 deletions

diff --git a/doc/bugs/Windows_file_timestamp_timezone_madness/comment_2_a6a3871747306913b69abcd73d13305e._comment b/doc/bugs/Windows_file_timestamp_timezone_madness/comment_2_a6a3871747306913b69abcd73d13305e._comment
new file mode 100644
index 000000000..c213aa0a9
--- /dev/null
+++ b/doc/bugs/Windows_file_timestamp_timezone_madness/comment_2_a6a3871747306913b69abcd73d13305e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-06-11T19:51:15Z"
+ content="""
+Note that multiple time zone changes complicate this. I think that means that the delta can't be simply applied when comparing inode caches. Instead, probably it needs to be applied when generating inode caches.
+
+A scenario:
+
+1. Time zone is at +1h when the inode sential is written.
+2. Time zone changes to +2h
+3. File F is added (with a current timestamp of T)
+4. Time zone changes to +5h
+
+I am a little confused by which way windows moves the timestamps when the time zone changes. Let's assume I might get the sign wrong.
+
+Let F's timestamp after step 4, F4 = T+-3h.
+
+Let the delta after step 4, D4 = +-4h  
+And, let the delta after step 2, D2 = +-1h
+
+If step 3 writes the current timestamp to the inode cache, then the cache still has T in it after step 4. F4+D4 /= T (T +-3h +-4h /= T). So comparison doesn't work.
+
+If instead the current delta is applied when generating inode caches (both for storing on disk, and for immediate comparison), then the inode cache will have T+D2 in it. Then after step 4, generating a new inode cache for F will yield F4+D4. So, does F4+D4 == T+D2? T +-3h +-4h == T +-1h YES!
+"""]]