Robocopy preserves file timestamps exactly as they exist on the source, so it does not convert UTC to local time or add an hour. The one-hour discrepancy you see in backups is almost certainly caused by a daylight saving time (DST) mismatch between the source and destination systems, or by the destination drive using a different timezone setting than expected.
Understanding How Robocopy Handles Timestamps
When you runrobocopy, it copies files with their original metadata intact. By default, Robocopy uses the /COPY:DAT switch, which stands for Data, Attributes, and Timestamps. This means the modification time, creation time, and last access time are copied verbatim from the source file to the destination file. There is no inherent logic in Robocopy that adjusts these times based on timezone differences during the copy operation itself.
If your backup shows timestamps that are exactly one hour newer, it indicates that the timestamp value stored in the file header on the source system was already shifted relative to what you expect, or the destination system is interpreting those timestamps differently due to its own clock configuration. It is crucial to understand that Robocopy is a passive tool in this regard; it moves the data bits and the associated metadata without alteration. If the source file says it was modified at 14:00, the destination file will say 14:00, regardless of whether one machine is in EST and the other in UTC.
For more details on how Robocopy handles file attributes and deletion logic, you might want to review Understanding Robocopy's /PURGE and /MOVE Options. While this article focuses on deletions, it reinforces the concept that Robocopy strictly adheres to the metadata provided unless explicitly told otherwise by specific switches.
The Daylight Saving Time Mismatch
The most common cause for a consistent one-hour shift in file timestamps is a mismatch in how the source and destination systems handle Daylight Saving Time. Windows stores file timestamps internally as Coordinated Universal Time (UTC). However, when you view these timestamps in File Explorer or via command-line tools, they are converted to the local time zone of the system displaying them. Consider this scenario: Your source server is located in a region that observes DST, and your backup destination is on a different server or external drive connected to a machine set to a different timezone. If the source file was created during standard time but the destination system interprets the UTC timestamp assuming it is currently in daylight time, the displayed local time will be off by one hour. Alternatively, if the clocks were adjusted incorrectly on either machine during the transition period, the UTC values themselves might have been written incorrectly at the source. To diagnose this, check the timezone settings on both the source and destination machines. Ensure that both systems have the correct current time and that the "Automatically adjust clock for Daylight Saving Time" option is enabled and functioning correctly in the Windows Date and Time settings. A drift in the system clock can also cause issues, though this usually results in larger discrepancies than exactly one hour.Verifying Source Timestamp Accuracy
Before blaming Robocopy, you must verify that the source files actually have the correct timestamps. Use thedir command in Command Prompt or Get-ChildItem in PowerShell to inspect the source files. Compare the output against the actual known modification dates of the files.
If the source files already show the wrong time (e.g., they are one hour ahead), then the problem lies with the source system's clock or the application that created the files, not with Robocopy. In this case, fixing the system clock on the source machine and re-running the backup will resolve the issue. You should also check if any automated processes or scripts are modifying the files immediately after creation, potentially updating the timestamp to the current time, which might differ from the intended logical creation time.
If you are syncing folders with multiple copies or complex structures, ensure that your Robocopy commands are not inadvertently triggering behaviors that update timestamps. For instance, using the /MIR (mirror) option can sometimes lead to unexpected behaviors if not carefully managed, especially when dealing with deleted files. See Syncing Two Folders with Robocopy for best practices on maintaining synchronization integrity without unintended side effects.
Checking Destination Drive Formatting and Clock Sync
Another potential culprit is the destination storage medium. If you are backing up to an external USB drive or a network share, ensure that the destination system’s clock is synchronized with a reliable time source. Network time protocol (NTP) synchronization issues can lead to significant time drift. Additionally, check the formatting of the destination drive. While NTFS fully supports preserving timestamps, older file systems like FAT32 have limitations. FAT32 only supports a granularity of two seconds and has a limited date range. If you are copying to a FAT32 drive, timestamps may be rounded or altered. Ensure your backup destination is formatted as NTFS or exFAT to maintain full timestamp fidelity. If you are encountering errors related to hidden partitions or shadow drives, such as error code 26, ensure that your target path is accessible and correctly configured. Refer to RoboCopy to hidden shadow drive partition; error code reads as Invalid Parameter #26 :x\\ for troubleshooting connectivity and parameter issues that might interfere with proper file handling.Conclusion
The one-hour shift in Robocopy backup timestamps is rarely a bug within Robocopy itself. It is almost always a result of timezone misconfiguration, DST handling errors, or inaccurate source clocks. By verifying the accuracy of the source timestamps, ensuring consistent timezone settings across all involved systems, and checking the destination drive format, you can resolve this issue. Always test with small sample sets to confirm that the timestamps match before running large-scale backup jobs.Frequently Asked Questions
Does Robocopy have a switch to force UTC timestamps?
No, Robocopy does not have a switch to force UTC display because it stores timestamps in UTC internally regardless. The display you see is determined by the local timezone of the system viewing the files. To see the true UTC time, you would need to use tools that specifically convert and display UTC rather than relying on File Explorer.Can I use PowerShell to fix existing bad timestamps in my backup?
Yes, you can use PowerShell scripts to iterate through files and set timestamps manually. However, this is generally unnecessary if you fix the root cause on the source system. If you must correct them, useSet-ItemProperty with the LastWriteTime attribute, adjusting the offset back by one hour if needed.
Why do some files show correct times and others are off by an hour?
This typically happens if the files were created at different times relative to the DST transition. Files created before the clock change might reflect standard time, while those created after reflect daylight time, causing a perceived inconsistency if the system clock or timezone interpretation is inconsistent during the copy process.Is /ZB necessary for preserving timestamps?
No,/ZB is used for restarting interrupted copies and accessing files with restricted permissions. It does not affect timestamp preservation. Timestamps are preserved by default with /COPY:DAT, which is the standard behavior. Using /ZB is recommended for reliability but has no bearing on time accuracy.