Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.59.5

log-hires-timestamp

Global

Whether to write milliseconds in the log
in the configuration this is a linelog-hires-timestamp falseinside the block Global
When the order of events matters more than their time

The line adds milliseconds to the timestamp: instead of 2026-08-28 15:54:31 the log shows 2026-08-28 15:54:31.593. The default is false.

The point is not precision but order. Within one second an ordinary timestamp does not distinguish events, and when investigating a race — which came first, the connection or the configuration reload — the log stops answering the question.

The price is a few bytes per line and a slightly noisier log when read by eye.

The line does not affect accounting — there the timestamp format is set separately, via iso-times in the <acct-file> block.

The main trap is enabling it in the hope of synchronizing with other logs. Milliseconds do not make the node’s clock more accurate: matching records against the receiver’s log or a neighboring service is still impossible without configured time synchronization.
What the Hub does. It does not write it — the default stays.

The line would come in handy when investigating a rare class of faults: when you need the order of events within a second — for example, whether applying the configuration managed to close a connection before the receiver took it.

Recommended values

Enabled for a specific investigation:

Value When
false (default) always
true investigating the order of events within a second
The default false and the look of a timestamp with milliseconds are from the manual (§ 3.3.1.59.5). The remark about order versus precision is ours.
Example configuration
# investigating a race: who came first within one second
log-file /var/log/pmta/log
log-hires-timestamp true
It does not affect synchronization with other logs: that needs a correctly running clock, not a finer timestamp.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Expecting milliseconds to match up with other logs

our experience

What it costsA finer timestamp does not improve clock agreement. Matching records from different machines without configured time synchronization is still impossible.
How to spot itThe node’s and the receiver’s records differ by seconds with milliseconds enabled.
How to do it rightConfigure time synchronization; milliseconds are for the order of events within one node.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
log-hires-timestamp <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.59.5
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line is written at the root of the file, the Global section, and concerns the node’s logs. Timestamps in accounting are configured separately — iso-times.
How to check on the node
The look of the timestamp is visible in any log line:
tail -2 /var/log/pmta/log
Three digits after the dot mean the line is enabled. Otherwise the timestamp ends with seconds.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Untangle a stuck queue