One easy workaround would be to, when you start the backup program, to set it to a timezone that does not have  daylight savings time shifts.  (eg: " TZ=MST  run_my_backup"  )<br><br>This can be done on a per-process (or per-user) basis by setting the TZ environment  variable before <br>
starting the process (or in a user's .*profile file)<br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 3:00 PM, Maurice Volaski <span dir="ltr"><<a href="mailto:mvolaski@aecom.yu.edu">mvolaski@aecom.yu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Time zones are the culprit -- Specifically DST shifts.<br>
If you check the absolute time stamp (which is GMT), it hasn't changed...<br>
but the distance between you and GMT changed by one hour when the DST change kicked in.<br>
Nothing has gone wrong, unless your backup software works internally with TZ shifted date stamps, in which<br>
case it might get confused twice per yer.<br>
<br>
</blockquote></div>
Thanks for you answer. It looks like a bug in the backup software.<br></blockquote></div><br>-- <br>Stephen Samuel <a href="http://www.bcgreen.com">http://www.bcgreen.com</a>  Software, like love, <br>778-861-7641                              grows when you give it away<br>