summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-06-12 15:17:32 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-06-12 15:17:32 -0400
commit53d185f8be9db8a79c9d628b8be7f06bc0d14537 (patch)
treef422cdbcc9e1bb39f1a9df2a6e4f5fe0540fe2bc
parent02d0cde4530e53a9608362d1a433d7e7c94cefbd (diff)
this just went from horrible to insanely weird
-rw-r--r--doc/bugs/Windows_file_timestamp_timezone_madness.mdwn30
1 files changed, 20 insertions, 10 deletions
diff --git a/doc/bugs/Windows_file_timestamp_timezone_madness.mdwn b/doc/bugs/Windows_file_timestamp_timezone_madness.mdwn
index 8b1f0ef8f..b92935f4f 100644
--- a/doc/bugs/Windows_file_timestamp_timezone_madness.mdwn
+++ b/doc/bugs/Windows_file_timestamp_timezone_madness.mdwn
@@ -5,14 +5,24 @@ appear to change.
This means that after such a change, git-annex will see new mtimes, and
want to re-checksum every file in the repo.
-The best way to fix this seems to be to normalize the timestamp returned by
-getFileStatus, which is relative to the current time zone, to be relative
-to UTC. (As is always the case on Unix, of course).
-However, to do that, I need to know the current timezone.
-
-Unfortunately, Data.Time.LocalTime.getCurrentTimeZone doesn't seem to really
-work on windows. It always returns a time zone 60 minutes from UTS in my tests,
-no matter what the zone really is. I need to test this more widely and file
-a GHC bug if appropriate.
-
[[!tag confirmed]]
+
+> Update: Actually, I seem to have been getting confused by behavior of
+> cygwin terminal setting TZ. That indeed led to timestamp changes when the
+> time zone changed. I have made git-annex unset TZ to avoid this.
+>
+> Without TZ set, time stamps are actually stable across time zone changes.
+> Ie, a simple program to read the time stamp of a file and print it
+> always shows the same thing, before and after a timezone change.
+>
+> However, and here's where it gets truely ghastly: A program that stats a
+> file in a loop will see its timestamp change when the timezone changes.
+> I suspect this might be a bug in the Haskell RTS caching something it
+> should not. Stopping and re-running the program gets back to the
+> original timestamp.
+>
+> I have not tested DST changes, but it's hard to imagine it being any
+> worse than the above behavior.
+>
+> So, that's insane then. We can't trust timestamps to be stable on windows
+> when git-annex is running for a long period of time. --[[Joey]]