SetFileTime()设置FILETIME为0xFF时文件日期显示差异原因咨询

Great question! Let's break down what's happening here step by step:

1. What FILETIME actually represents #

First, remember that the FILETIME structure stores a 64-bit value counting 100-nanosecond intervals since 00:00:00 UTC on January 1, 1601. That's the official epoch for Windows timekeeping.

When you set your FILETIME to 0xFF, you're creating a value of 255 (decimal) 100-nanosecond intervals. That's just 25.5 microseconds after the Windows epoch—so technically, it's still January 1, 1601 00:00:00.0000255 UTC.

2. Why File Explorer Details Mode shows blank #

File Explorer's Details view (Ctrl+Shift+6) has built-in logic to handle dates outside what it considers a "valid" or commonly used range. Dates as early as 1601 are way outside the typical scope of file timestamps (most modern systems never deal with files from the 17th century!), so the UI component simply hides the value instead of rendering it. This is a deliberate design choice to avoid confusing users with unexpected, ancient dates.

3. Why file properties show "02 Jan 1601" #

This boils down to time zone conversion and how Windows processes extremely early timestamps:

• The raw FILETIME value is in UTC. When Windows displays this in the file properties dialog, it converts it to your local time zone.
• If your local time zone is ahead of UTC, adding that offset to the very early UTC time of January 1, 1601 00:00:00 could push the time into the next day. Compounding this, Windows' time zone database includes historical rules for regions that didn't use standardized time zones in the 17th century—these older offset rules might create a larger shift than modern time zones, resulting in the local date showing as January 2.
• There's also a minor edge case in Windows' date conversion functions: when handling extremely small FILETIME values close to the epoch, off-by-one errors can occur during conversion to a human-readable format, leading to the displayed day being January 2 instead of January 1.

4. Quick recap #

• 0xFF in FILETIME is a tiny value just after the Windows epoch (Jan 1, 1601 UTC).
• Details view ignores this ultra-early date, showing a blank field.
• Properties dialog converts the UTC time to local time, which (due to time zone/historical rules) shifts to Jan 2, 1601.

内容的提问来源于stack exchange，提问作者Biswapriyo