Knowledge base

iso-times

<acct-file>

Timestamp format in accounting records
in the configuration this is a lineiso-times yesinside the block <acct-file>
What time looks like in the file

The line sets the form of timestamps. The default is yes, that is, ISO format.

The alternative is the number of seconds since the start of 1970. It is more compact and more convenient for a machine, but unreadable for a human and requires knowing the time zone separately.

ISO format carries the zone offset within it — that is what makes it good for a fleet whose nodes are in different countries: a record stays unambiguous without knowing where the node that wrote it is.

The line concerns only accounting. It does not affect the engine log or message headers.

The main trap is turning it off for compactness and getting ambiguity. A number of seconds does not store the zone, and on a fleet of nodes in different zones parsing becomes dependent on where the node stood. The saving is a few bytes per record.
What the Hub does. It does not write it — the default remains, that is, ISO. This is convenient for us too: the receiver parses timestamps without extra assumptions about the node’s time zone.
Recommended values

There is almost never a need to change it:

Value When
yes (default) always
no the accounting receiver requires seconds since the epoch
The yes default and the choice between formats itself come from the manual (§ 3.3.11.7, § 12.1.2.2). The argument about a fleet across time zones is ours.
Example configuration
# the default written explicitly — the timestamp carries the zone offset
<acct-file /var/log/pmta/acct.csv>
    records d, b
    iso-times yes</acct-file>
Writing the default explicitly makes sense where the accounting file is parsed by someone else’s program: the line answers its question without reading the manual.
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▶

Switching the format on a working accounting stream

our experience

What it costsThe parsing program gets timestamps of a different kind in the middle of a file or a batch. A parse error is not guaranteed — a silent distortion of time is possible too.
How to spot itAnalytics shows events dated 1970 or shifted by hours.
How to do it rightChange the format only together with the parsing side, and on a live stream by creating a new accounting block.
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
iso-times <boolean>
Values
yes | no | true | false
Default
yes § 3.3.11.7
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<acct-file>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <acct-file> and concerns only the timestamps of its records. Two accounting streams can write time differently.
How to check on the node
The format is visible in the file itself — one record is enough:
head -2 "$(ls -t /var/log/pmta/acct-*.csv | head -1)"
A timestamp like 2026-08-28T12:34:56+03:00 is ISO format. A bare number is seconds since the epoch, and the zone has to be known separately.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry