The -1 sentinel
Kafka's no-timestamp value, which is not a date and must not be converted as one
1700000000000 1700000000 -1
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.
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.
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.
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.
Kafka's no-timestamp value, which is not a date and must not be converted as one
1700000000000 1700000000 -1
The same digits read as seconds, milliseconds, microseconds and nanoseconds
1700000000000000
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
The result lands in 1970, which looks like an uninitialised value and gets investigated as a bug.
Instead:Count the digits. Thirteen is milliseconds.
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.
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.
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.
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.
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.
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.
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.