When Squid’s Access Log Appears to Be Years Behind

Squid’s native access format starts with an epoch timestamp, conventionally written as %ts.%03tu: seconds since the epoch followed by three digits of milliseconds. A value in that position is not a formatted calendar date.

First check the active access_log format. For Squid 7, review access_log’s output and format selection for the instance. A custom log format, a syslog prefix or a downstream log processor can put a different timestamp at the beginning of the displayed line.

Three checks narrow it down

1. Decode the numeric value using the correct unit. The fractional digits are part of a seconds value, not a separate whole timestamp in milliseconds.
2. Compare the decoded UTC time with the local-time display. A timezone difference can move the displayed hour and sometimes the calendar day; it does not explain a date many years away.
3. Compare a fresh record with the clock of the machine running that Squid instance. On a systemd host, timedatectl status reports clock settings and synchronization status.

If the host clock is wrong too, investigate its time synchronization and, where applicable, virtual-machine time configuration. A single implausible log date is insufficient to identify a failed hardware clock battery.

If the host clock is correct, confirm that the file is current and belongs to that instance. Check rotated archives, remote collectors and timestamp conversions in the viewing tool.

Also distinguish the transaction timestamp from the time a collector receives the line. Normal access logging occurs at request completion, and daemon logging can write asynchronously. A long-running request or tunnel need not appear at its initial connection time.