ObservKit / Tools / Unix Timestamp Converter
Developer utility

Unix Timestamp Converter

Convert Unix seconds or milliseconds to a readable UTC date without sending data anywhere.

● Calculated locally in your browser
Unix timestamp
10 digits are treated as seconds; 13 digits as milliseconds.
Readable date · UTC
2025-01-01 00:00:00 UTCWednesday, January 1, 2025

Timestamps in logs

A Unix timestamp counts time since 00:00:00 UTC on 1 January 1970. Log pipelines mix four precisions, and the digit count of a present-day value tells them apart:

173568960010 digits — seconds
173568960000013 digits — milliseconds
173568960000000016 digits — microseconds
173568960000000000019 digits — nanoseconds

The converter treats values with at least 12 digits as milliseconds and smaller ones as seconds. Divide microseconds by 1,000 and nanoseconds by 1,000,000 before converting; read as milliseconds, the 16-digit value above would land in the year 56971.

Splunk _time

At index time Splunk converts each event's timestamp to Unix time and stores it in _time; the UI renders it in the user's zone. When the raw event has no zone, Splunk resolves one in order: a zone in the event text, a TZ setting in props.conf for the source, host or sourcetype, the zone sent by the forwarder, then the zone of the system running splunkd.

Elasticsearch @timestamp

Date fields are stored as milliseconds since the epoch in UTC. The default format accepts ISO 8601 strings or epoch_millis; seconds are only accepted if epoch_second is added to the field's format. Sending a seconds value to a default date field is a classic error: 1735689600 read as milliseconds is 1970-01-21T02:08:09.600Z. Use date_nanos when nanosecond precision matters.

Timestamps outside the expected range

Splunk compares each extracted timestamp with the current time: MAX_DAYS_AGO and MAX_DAYS_HENCE in props.conf limit how far in the past or future an extracted date may be before Splunk discards it and assigns a different timestamp. A source that writes two-digit years or a misparsed day/month order can therefore land events on the wrong day without any error. Check new sources by comparing _time with _indextime for a sample of events; a consistent offset of whole hours points to a time zone problem, a random spread to a parsing problem.

Time zone ingestion errors

Illustrative example Application servers at UTC−3 write 2026-10-08 09:00:00 without an offset and relay it through a syslog server running in UTC. If the forwarder reads it there and no TZ is set, the event is stored as 09:00 UTC — three hours earlier than it happened (12:00 UTC). A 15-minute alert search then never sees those events in its window. Fix it at the source with an explicit offset, or set TZ for that source.

Sources

Last reviewed: