The -1 sentinel
Kafka's no-timestamp value, which is not a date and must not be converted as one
1700000000000 1700000000 -1
Kafka Timestamp Converter
Convert Kafka record timestamps, one per line, from whichever unit you have. Kafka stores milliseconds; the report says how each input was read, because a bare number is ambiguous between four units.
Detection uses the digit count, which is the only signal a bare integer carries. A seconds value read as milliseconds lands in 1970, which reads as a plausible bug rather than an impossible date, so it is the direction worth stating the unit for.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Four possible units
The same digits read as seconds, milliseconds, microseconds and nanoseconds
1700000000000000
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Converting -1 as a date
It is Kafka's sentinel for no timestamp, and it is also what offsetsForTimes returns when no record matches.
Instead:Treat it as a sentinel. Converting gives December 1969.
Reading seconds as milliseconds
The result lands in 1970, which looks like an uninitialised value and gets investigated as a bug.
Instead:Count the digits. Thirteen is milliseconds.
Assuming a record timestamp is the event time
With the default CreateTime it is whatever the producer set, which can be wrong or in the future. With LogAppendTime the broker overwrites it.
Instead:Check message.timestamp.type on the topic before trusting it.
A Kafka timestamp is milliseconds, and means one of two things
The unit is only ambiguous on the way in. The meaning is ambiguous permanently, and it depends on a topic setting rather than on anything in the record.
Kafka stores milliseconds, always
Every record timestamp in every message format is milliseconds since the Unix epoch. The ambiguity is entirely in what you have in front of you: a bare integer could be seconds from a log line, milliseconds from Kafka itself, microseconds from a database or nanoseconds from a tracing system, and the digit count is the only available signal.
Seconds read as milliseconds lands in 1970
This is the dangerous direction. 1700000000 read as milliseconds is January 1970, which looks like an uninitialised value or a plausible bug, so it gets investigated as one. The reverse mistake puts the date somewhere around the year 56,000, which is at least obviously wrong and gets fixed in seconds. That asymmetry is why the reading is always reported here rather than assumed.
CreateTime and LogAppendTime are completely different fields
With message.timestamp.type=CreateTime, the default, the timestamp is whatever the producer put there. It can be in the future, it can be wrong, and it is not monotonic across a partition, because two producers do not share a clock. With LogAppendTime the broker overwrites it on append, which makes it monotonic and reliable and destroys the producer's own event time. Neither is better; they answer different questions.
A topic can hold both
Switching message.timestamp.type does not rewrite existing records, so a topic that changed at some point holds records written under each. Anything that assumes one meaning across a whole partition is wrong for the records on the other side of that change, and there is nothing in the record to say which it was.
What this cannot see
It cannot tell you which timestamp type a topic uses, because that is a topic config rather than anything in a timestamp. -1 is Kafka's sentinel for no timestamp and is reported as a sentinel rather than converted, and it is also what offsetsForTimes returns for a partition with no matching record. For the general case outside Kafka, the Unix timestamp converter on this site handles the same units without the Kafka specifics.
Related kafka tools
Kafka Retention and Unit Converter log.retention.hours does not take milliseconds Kafka Connect Worker Config Generator Security three times, or the tasks fail Kafka .properties to YAML Converter Dotted keys stay flat Kafka ZooKeeper to KRaft Config Converter The authorizer class nobody changes Kafka Config to Strimzi Half of it belongs elsewhere Kafka Connect Pipeline Visualizer The order things really run in
All 73 kafka tools