Epoch / Unix Time Converter

About Epoch / Unix Time Converter

Unix time is seconds since 1 January 1970 UTC. Every log pipeline, database and API uses it, in four different precisions, usually without saying which. This detects the precision from the magnitude and converts in both directions.

Correlating logs across systems

Timestamps only correlate if every device agrees on the time and records the offset. Store and compare in UTC, keep NTP healthy on everything that logs, and prefer RFC 3339 output (2026-07-24T22:15:03.123Z) over the legacy BSD syslog format, which has neither a year nor a timezone. When an incident spans a daylight-saving boundary, local timestamps produce either a missing hour or a duplicated one — both of which reorder events in a way that misleads the reader.

Telling the precisions apart

A 10-digit value is seconds, 13 digits is milliseconds, 16 is microseconds and 19 is nanoseconds. Java, JavaScript and Kafka use milliseconds; C, Python, Go and most Unix tooling use seconds; eBPF and tracing tools use nanoseconds. Mixing them up produces timestamps in 1970 or in the year 54,000 - both are immediately recognisable once you know the pattern.

Common use cases

• Reading a timestamp out of a raw log or database row.
• Correlating events across systems that report time differently.
• Setting an absolute expiry value in a token or scheduled job.

Edge cases and gotchas

• Leap seconds are not represented in Unix time; do not use it to measure precise intervals across one.
• Always store and compare in UTC. Local time in logs turns every daylight-saving change into an outage postmortem.