A copied Windows file appears to have a different modification time on another computer. Before copying it again or changing the clock, compare its UTC modification timestamp. A local-time display depends on the viewing computer’s time-zone rules; UTC gives you a common reference. However, matching timestamps do not prove that two files contain identical bytes, and different timestamps do not by themselves prove corruption.
This workflow reads one file’s metadata without changing its contents or setting its timestamps. Use it to improve a troubleshooting record, not to certify a backup or establish a forensic timeline.
Start with the exact file, not a wildcard match
Open PowerShell as your normal user. Replace the example path with an existing test document that you are allowed to inspect. Do not paste a production path blindly. The example deliberately contains square brackets: -LiteralPath treats these as filename characters instead of wildcard syntax.
$file = Get-Item -LiteralPath 'C:\Users\Public\Documents\report[final].txt' -ErrorAction Stop
if ($file.PSIsContainer) {
throw 'Choose a file rather than a directory.'
}
$file.Refresh()
[pscustomobject]@{
FullName = $file.FullName
LengthBytes = $file.Length
ModifiedLocal = $file.LastWriteTime.ToString('o')
ModifiedUtc = $file.LastWriteTimeUtc.ToString('o')
}Get-Item retrieves the item itself, not the text inside it. -ErrorAction Stop prevents a lookup error from being treated as a valid inspection. If the command fails, resolve the path or permission problem rather than interpreting missing output as an old timestamp. For more on exact names, see opening filenames containing square brackets with LiteralPath.
Read the two timestamp fields as different representations
The ModifiedLocal field displays the modification time in the machine’s local time context. ModifiedUtc uses the file object’s UTC property. The round-trip format string 'o' makes the date, time and fractional seconds explicit instead of relying on a short regional display.
Run the same inspection on the other computer, using that computer’s actual file path. Keep the full path and byte length beside each result so that similarly named files are not accidentally compared. Compare the UTC fields first. If UTC matches but the local display differs, investigate the computers’ time-zone settings and how the original application displayed time before concluding that the copy changed the file.
Do not manually add a fixed number of hours to every record. Daylight-saving rules and the date being represented can matter. Equally, do not change a system clock just to make two screenshots look alike. Preserve the original observations and record any later correction separately.
Refresh helps with cached metadata, not historical accuracy
Microsoft documents that file-system metadata can be cached and recommends Refresh() to obtain the latest value. That is why the example refreshes the object immediately before displaying its properties. It does not continually watch the file: another process can change it after the read.
The same documentation warns that native timestamp values may not be continuously updated by the operating system. Filesystems and copying tools can also differ in how they preserve or represent timestamps. Treat a timestamp discrepancy as a question to investigate, not an automatic finding that an application lost work.
Separate modification evidence from content verification
There are three different questions: what metadata is currently reported, whether the two files contain the same bytes, and whether a backup can actually restore the required work. This inspection answers only the first. Equal lengths and equal UTC times are useful clues, but neither is a content comparison.
If the UTC times differ, first confirm that both paths point to the intended versions. Then review the copy tool’s timestamp behaviour and whether either file was edited after copying. If content integrity matters, use an appropriate separate byte or cryptographic-hash comparison and a restore test for backup assurance. Do not overwrite the only remaining version while investigating.
Quick checklist and common questions
- Record both full paths and capture the results close together.
- Use the same UTC property on both machines.
- Keep lookup failures separate from valid timestamp results.
- Preserve both versions until the discrepancy is understood.
Does UTC prove which person edited the file? No. File metadata does not identify an editor or establish an unalterable audit history.
Does this command repair anything? No. It reads metadata; it does not synchronise clocks or restore contents. Validate the example with a disposable file in your own Windows environment.
Sources: Microsoft Get-Item documentation and LastWriteTimeUtc reference and caching caveats.
This tutorial is for educational purposes. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
