Introduction

Yes. In modern Kafka, records include a timestamp by default. Since Kafka 0.10.0.0, each record has a timestamp field that can represent either the producer's creation time or the broker's log append time, depending on topic and broker configuration.

So the practical answer is not just "yes." It is "yes, and you need to know which timestamp semantics you are getting."

The Two Timestamp Modes

Kafka supports two main timestamp types:

• 'CreateTime'
• 'LogAppendTime'

CreateTime means the record carries the timestamp supplied by the producer, or a producer-generated current time if none was set explicitly.

LogAppendTime means the broker overwrites that value with the time the record was appended to the log.

The broker or topic configuration determines which one is used.

Default Behavior

In most Kafka setups, the default timestamp type is CreateTime.

That means records usually include a timestamp even if you do not explicitly set one in application code.

Producer example in Java:

ProducerRecord<String, String> record =
    new ProducerRecord<>("events", "key", "value");
producer.send(record);

Even though no timestamp was passed here, the record still gets one under the normal CreateTime mode.

Setting a Timestamp Explicitly

You can also provide a timestamp yourself.

1long ts = System.currentTimeMillis();
2ProducerRecord<String, String> record =
3    new ProducerRecord<>("events", null, ts, "key", "value");
4producer.send(record);

This is useful when the event time in your business logic differs from the time the producer happens to publish the message.

For example, an event might represent a click that occurred earlier and was buffered before sending.

Reading the Timestamp as a Consumer

Consumers can read the record timestamp directly.

1for (ConsumerRecord<String, String> record : records) {
2    System.out.println(record.timestamp());
3    System.out.println(record.timestampType());
4}

That second call is important because it tells you whether the timestamp reflects CreateTime or LogAppendTime.

If your stream processing logic depends on event time semantics, do not assume the meaning of the timestamp blindly.

Why This Matters

Record timestamps are important for:

• stream processing windows
• retention and time-based queries
• debugging event flow
• ordering analysis across producers

In Kafka Streams and similar frameworks, timestamp meaning can directly affect windowed aggregation results. A record with broker append time may behave differently from a record using true event creation time.

Configuration Considerations

Kafka lets you choose timestamp behavior through the broker or topic setting for timestamp type.

Operationally, the choice is usually:

• 'CreateTime when producer event time should be preserved'
• 'LogAppendTime when broker arrival time is more trustworthy or easier to standardize'

Which one is correct depends on the use case. There is no single universal right answer.

Common Pitfalls

The biggest mistake is assuming Kafka timestamps exist only when you set them manually. In modern Kafka, records normally include timestamps by default.

Another common issue is assuming the timestamp always means producer event time. It may instead be broker append time if LogAppendTime is configured.

People also forget to check timestampType() on the consumer side and then build time-based logic on the wrong assumption.

Finally, if you need precise event-time semantics, do not rely on defaults without documenting them. Make the timestamp model explicit.

Summary

• Kafka records include timestamps by default in modern Kafka.
• The two timestamp modes are CreateTime and LogAppendTime.
• Most setups default to CreateTime.
• Producers can set timestamps explicitly, but they do not have to.
• Consumers can read both the timestamp value and its type.
• Time-based processing should always verify which timestamp semantics are in use.