Add .gitignore file.
[rsync-web.git] / daylight-savings.html
1 <HTML><HEAD>
2 <TITLE>DST change and date comparisons</TITLE>
3 </HEAD><BODY>
4
5 <p><small><i>J.W. Schultz wrote the following text in a
6 <a href="http://www.cygwin.com/ml/cygwin/2003-10/msg00995.html">post</a>
7 to the cygwin mailing list.&nbsp; It has been slightly edited and beautified
8 for inclusion here.</i></small>
9
10 <h1>How the DST Change can adversely affect FAT filesystems</h1>
11
12 <p>
13 The vernal and autumnal transitions to and from daylight-savings
14 time have important implications
15 for those with Microsoft systems and use utilities that
16 compare file timestamps on different filesystem types or
17 with filesystems on other operating systems that can lead to
18 a problem in how the file's date is handled.
19 This problem lies in the way FAT filesystems stores
20 timestamps and how Windows converts between local time and
21 UTC. 
22
23 <h2>Background</h2>
24
25 <p>
26 In UNIX and UNIX-like systems (such as Linux) file timestamps
27 are stored in UTC (universal time) and are only converted to
28 local-time by user-space programs for display purposes.&nbsp; At
29 the system call level all time values are in UTC and
30 utilities that compare timestamps do so in UTC.&nbsp; Also, the
31 standard UTC-&gt;local and local-&gt;UTC conversion functions are
32 aware of DST and conversions reflect this so that if a
33 timestamp was recorded during ST it will be converted using
34 the ST offset even when the current system time is DST.
35
36 <p>
37 In Windows things are not so simple.&nbsp; Windows operates in
38 local-time.&nbsp; Timestamps in the various FAT derived
39 filesystems are stored in local-time.&nbsp; Timestamps in NTFS
40 filesystems are stored in UTC.&nbsp; This inconsistency is
41 further complicated by the fact that the conversion routines
42 used are not DST aware.&nbsp; Instead of being DST aware the
43 system has a fixed offset to convert between local-time and
44 UTC regardless of the date in the timestamp.&nbsp; This fixed
45 offset is calculated at boot time and only changed when
46 systems transition to or from DST.&nbsp; As a result the apparent
47 modification time of a file on NTFS as reported in a windows
48 utility will change by one hour when reported in local-time
49 and FAT based files when reported in UTC.
50
51 <p>
52 The difficulty that this produces is that any utilities that
53 compare timestamps between FAT and NTFS filesystems or
54 between Windows and other platforms will view files that
55 have not changed as having a different modified time.&nbsp; Among other things
56 this will affect rsync, rdiff, unison, wget, and make.&nbsp; However,
57 for the purposes of this document, we will only discuss rsync.
58
59 <p>
60 With the reduced cost of hard disks many newer backup
61 systems are using hard disk based storage and take advantage
62 of timestamp comparison to detect file changes for the sake
63 of efficiency.&nbsp; Rsync is probably premier in this role and
64 is used by a fair number of free and even commercial backup
65 systems as well as being the basis for many home-brew backup
66 solutions.
67
68 <p>
69 With rsync and similar systems the effect of this is that
70 every file will appear to have been changed.&nbsp; The result is
71 any space savings associated with linking (--link-dest) or
72 with decremental backup approaches (--compare-dest and
73 --backup-dir) will be defeated.&nbsp; Perhaps worse, because
74 every file will appear to have changed the time required to
75 do a backup or a non-backup rsync will be much longer than
76 normal.&nbsp; In some cases backups that normally complete in
77 less than one hour can take several days.
78
79 <p>
80 So what can be done about it?  Several things, there are
81 ways to merely mitigate the problem, to correct it and finally
82 to prevent the problem entirely.
83
84 <h2>Mitigation</h2>
85
86 <p>
87 Rsync has a --modify-window option.&nbsp; Many of you already use
88 --modify-window=1 to cope with the fact that windows often
89 stores timestamps with a two second resolution.&nbsp; Using a
90 --modify-window=3601 will cause rsync to ignore timestamp
91 differences of up to one hour.
92
93 <p>
94 This if often not particularly dangerous because a file would have to
95 be changed, synced and changed again without changing size
96 within a single hour and have no subsequent changes for this copy
97 to miss a file change.&nbsp; However, for some systems any such risk is
98 unacceptable, so other solutions are needed.
99
100 <h2>Correcting the Timestamps</h2>
101
102 <p>
103 There are two ways to correct.
104
105 <p>For the first run after the time change, you can run rsync with the
106 --checksum option in order to ensure that only files that have a changed
107 checksum get transferred, and update the modified time on all unchanged
108 files.&nbsp; This option has the drawback that it increases disk I/O by
109 a large amount on both the sending and receiving side, slowing down the
110 copy.
111
112 <p>
113 The other way to correct things is to change the timestamps
114 on the files on the backup server before doing a copy after a
115 time change has occurred.
116
117 <p>
118 Included here is an example perl script that will change the
119 timestamps of files in a list on standard-input.&nbsp; Whether
120 you use a positive or negative shift will depend on which
121 end you decide to adjust.
122
123 <p>
124 This is an example of how to use the script:
125
126 <blockquote><pre>
127 touch -d '01:00 13-apr-03' /tmp/cmpfile
128 find . -type f ! -newer /tmp/cmpfile | shifttime.pl 3600
129 </pre></blockquote>
130
131 <hr>
132 <pre>
133 #!/usr/bin/perl
134 use strict;
135
136 my $offset = shift() + 0;
137 die &quot;Usage: $0 OFFSET_SECONDS\n&quot; unless $offset;
138
139 while (&lt;&gt;) {
140     chomp;
141     my $mtime = (stat $_)[9];
142     next unless $mtime;
143     $mtime += $offset;
144     utime $mtime, $mtime, $_;
145 }
146 </pre>
147 <hr>
148
149 <h2>Prevention</h2>
150
151 <p>
152 To prevent the problem in the first place you need to
153 prevent changing to DST.&nbsp; This can be done by either running
154 the windows system in UTC, by disabling DST and changing
155 the system time manually twice each year, or by avoiding the use
156 of the FAT filesystem (perhaps by switching to a different OS).
157
158
159 <h2>Notes and References</h2>
160
161 <p>
162 Here are some references that Wayne Piekarski collected
163 while researching this problem.&nbsp; They contain a lot of
164 information about the ways that Windows deals with
165 timestamps on NTFS and FAT filesystems.
166
167 <p>
168 <a  href="http://optics.ph.unimelb.edu.au/help/rsync/rsync_pc1.html#gotchas">http://optics.ph.unimelb.edu.au/help/rsync/rsync_pc1.html#gotchas</a></br>
169 <a  href="http://list-archive.xemacs.org/xemacs-nt/199911/msg00130.html">http://list-archive.xemacs.org/xemacs-nt/199911/msg00130.html</a></br>
170 <a  href="http://p2p.wrox.com/archive/c_plus_plus_programming/2001-06/53.asp">http://p2p.wrox.com/archive/c_plus_plus_programming/2001-06/53.asp</a></br>
171 <a  href="http://www.codeproject.com/datetime/dstbugs.asp">http://www.codeproject.com/datetime/dstbugs.asp</a></br>
172 <a  href="http://support.microsoft.com/default.aspx?scid=kb;[LN];158588">http://support.microsoft.com/default.aspx?scid=kb;[LN];158588</a>
173
174 <p>
175 I wish to thank Wayne Piekarski for having copiled the
176 references and also supplying some additional insights.
177
178 <p>
179 Permission is granted without reservation reprint and
180 distribute this in whole and in part to any interested
181 parties.
182
183 <p>&mdash;J.W. Schultz