How Unrar Handles an Incorrect System Clock

When extracting archives, unrar primarily relies on the metadata stored inside the archive headers rather than the host machine's current system clock. This article explains how unrar assigns file timestamps during extraction, how a drastically incorrect system clock affects file attributes, and the filesystem or operational anomalies that can occur as a result.

Preservation of Stored Modification Times

By default, unrar does not use the current system time to set the modification date (mtime) of extracted files. Instead, it reads the timestamp stored within the RAR archive and applies it to the extracted file using operating system system calls, such as SetFileTime on Windows or utime/futimens on Unix-like platforms.

Because unrar explicitly overwrites the modification time with the archived value, an incorrect system clock will not alter the modification date of successfully extracted files.

Impact on Creation and Access Times

While modification time is preserved, other file timestamps depend on the archive version and specific extraction flags:

  • Access Time (atime): The operating system often marks the file access time as the moment the file was written to disk. If the system clock is incorrect, the access time will reflect that incorrect system time unless the archive includes stored access times and the user extracted with full precision timestamp switches (e.g., -ts).
  • Creation Time (ctime / Birth Time): On filesystems that support file creation timestamps (such as NTFS or ext4), the operating system assigns the current system time as the file's birth time during creation. If the system clock is set decades in the past or future, the file's creation time will inherit that error, potentially resulting in a creation date that is newer or older than its stored modification date.

Timestamp Range and Filesystem Limits

If a drastically incorrect system clock causes interactions with system-level time boundaries, issues can arise:

  • Epoch Violations: On Unix-based systems using 32-bit signed timestamps, dates before January 1, 1970, or after January 19, 2038, cannot be properly represented. If an incorrect clock causes an application or timezone calculation to wrap past these limits, calls to set the timestamp may fail silently or produce an error, leaving the file with a fallback timestamp.
  • "Future" File Warnings: If the system clock is set to a past date (such as 1980) and files from 2024 are extracted, the operating system and downstream utilities will view those files as existing in the future. While unrar itself will complete the extraction without blocking the operation, subsequent tools such as backup software, version control systems, or build tools like make may behave unpredictably or trigger clock skew warnings.

RAR Format Differences: RAR4 vs. RAR5

The format version of the archive influences how time is calculated:

  • RAR 4.x: Stores timestamps in MS-DOS local time format. If the system clock is drastically wrong, especially regarding daylight saving transitions or timezone settings, unrar may calculate local-to-UTC conversions improperly, introducing hour-level offsets.
  • RAR 5.0+: Stores timestamps in UTC with high precision (up to nanoseconds). unrar translates this UTC timestamp directly to the target filesystem, making it largely immune to local system clock errors, provided the target filesystem supports the date range.