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