Timestamped, parseable logs: RFC 5424 versus RFC 3164, JSON templates, and why UTC

What it is

RFC 3164, describing the legacy BSD syslog protocol still emitted by many devices, defines a message as a PRI part followed by a HEADER and MSG; its timestamp has no year and no time zone, and its precision is one second. RFC 5424 replaced it with a structured format whose HEADER always contains PRI, VERSION, and a TIMESTAMP field defined as either the NILVALUE - or FULL-DATE "T" FULL-TIME, explicitly derived from RFC 3339, which adds the year, fractional seconds and an explicit time zone offset (or Z for UTC). RFC 5424 itself states that the timestamp described in RFC 3164 "offers less precision than the timestamp specified in this document" and "also lacks the year and time zone information" — which is exactly why messages moving between the two formats need special handling: converting 5424 to 3164 means dropping the year and zone, and converting 3164 to 5424 means guessing both.

rsyslog can emit either style through built-in templates (RSYSLOG_SyslogProtocol23Format for 5424-style, RSYSLOG_TraditionalForwardFormat for 3164-style), or a custom structure entirely: a list template with option.jsonf="on" and property(... format="jsonf") fields renders selected properties, including timestamps, as a correctly escaped JSON object, which is far easier for a downstream parser or agent to consume reliably than free-text.

Why it matters

An agent or script that greps or regex-parses log timestamps needs to know, without guessing, what format it is looking at, what precision it carries, and what time zone applies. A 3164-style timestamp has no year, so a message logged around New Year is genuinely ambiguous to reconstruct months later. A 5424-style timestamp with an explicit offset, or a JSON field carrying an ISO 8601/RFC 3339 string, removes that ambiguity by construction.

How to apply

• Prefer sources and forwarders configured for RFC 5424 output over legacy RFC 3164 when the choice is available.
• When building a custom rsyslog template for a log-analysis pipeline, emit timestamps in RFC 3339 form with an explicit Z or offset, and consider a jsonf-based template so field boundaries are unambiguous.
• Set servers' time zone to UTC (timedatectl set-timezone UTC, as root), or at least log an explicit UTC offset in every timestamp, so that correlating events across hosts in different local time zones needs no conversion step.
• When parsing third-party logs, detect the format first (presence of a 4-digit year and an offset/Z suggests 5424/RFC 3339; a 3-letter month with no year suggests 3164) rather than assuming one.

Pitfalls

• Assuming all "syslog" messages share one timestamp format; RFC 3164 devices are still common in the field.
• Storing logs in local time without an offset, which makes a daylight-saving transition or a multi-region deployment impossible to order correctly after the fact.
• Dropping leading zeros from fractional seconds when reformatting, which RFC 5424's appendix A.4 calls a very common coding error: .003 written as .3 turns 3 ms into 300 ms.