PE Timestamps: Compile Time, Debug Time and Signing Time

TL;DR. A PE file carries several times: the COFF TimeDateStamp (the classic "compile time"), copies of it in the debug and export directories, and, if signed, a signing time. None is authoritative alone. Reproducible builds replace the value with a hash; attackers zero, randomise or copy it. Consistency between times is the useful signal.

Where the times are

Time	Location	Written by	Notes
Compile time	COFF header `TimeDateStamp`	linker	Unix seconds, UTC
Debug time	each `IMAGE_DEBUG_DIRECTORY` entry	linker	normally equal to the compile time
Export time	export directory `TimeDateStamp`	linker	DLLs; often equal, sometimes 0
Resource time	resource directory headers	resource compiler	usually 0
Signing time	Authenticode signed attribute or timestamp token	signer or timestamp authority	only the countersignature / RFC 3161 time is vouched for

The PE Parser shows all of them in a file's overview and lets you filter a whole collection by compile, debug or signing time.

Reproducible builds: when the timestamp is a hash

Since Windows 10, Microsoft builds much of the OS so that the same source produces the same bytes. The timestamp field then holds a hash of the content, which is why system files show dates decades away. Raymond Chen explains it in Why are the module timestamps in Windows 10 so nonsensical?. Such binaries have a debug directory entry of type 16, IMAGE_DEBUG_TYPE_REPRO. The .NET SDK does the same by default for its assemblies.

The PE Parser detects the REPRO entry, labels the value as a hash and leaves the file out of compile-time filtering instead of placing it in 2089.

Values that tell a story

0: some toolchains and many tampered files. Look at the other times.
1992-06-19 22:22:17 UTC (0x2A425E19): the fixed value written by older Borland Delphi linkers — it identifies the toolchain, not a date.
In the future (without REPRO): hand-edited, forged, or a build machine with a wrong clock.
Before 1995: implausible for a PE file; forged or random.
Compile ≠ debug time by more than a day: one of them was edited — a classic sign of timestomping, because tools that patch the header often forget the debug directory.
Signed before compiled: impossible; one of the two is false.

Using times in a case

Group, don't prove. Builds of one tool compiled days apart, sharing an imphash, tell you about the attacker's development cycle. The sample collection in the PE Parser has two builds of m64.exe compiled on 2026-09-03 and 2026-09-12.
Compare with the host. A binary compiled after it appeared on disk (file-system, Prefetch or Amcache first-seen times) has a forged header.
Trust the timestamp authority most. An RFC 3161 token or countersignature is issued by a third party at signing time; the signer's own signingTime attribute is not (Authenticode offline).
Note the zone. All PE times are UTC. Present them in UTC in reports and state the zone of any local conversion.

The time-range bar of the PE Parser works on these fields for a batch of files: pick the field, set From/To to the second or use "around this time" ±5 min / ±1 h / ±24 h from any file, and every count, list and export follows the range. The PE format guide puts the times in the context of the other headers.

FAQ

Where is the compile time of a Windows executable?

In the TimeDateStamp field of the COFF file header, as seconds since 1970-01-01 UTC. The linker usually writes the same value into the debug directory entries and the export directory.

Why do some Windows files have compile dates in the future or far in the past?

Recent Microsoft and .NET toolchains build reproducibly and store a hash of the content in the timestamp field instead of a time. A debug directory entry of type REPRO marks those files.

Can a PE compile timestamp be trusted?

Not on its own: it is a plain field anyone can edit. Compare it with the debug and export timestamps, the signing time from a timestamp authority, and file-system times on the machine.