...

The broker uses −1 as a default value for missing timestamp. Which might be a correct value set by the user: Wednesday, December 31, 1969 11:59:59 PM UTC.

 Options we have are:

...

Prosed behavior is ignore that problem and it is a choice of the user to:

1. interpret this value as a real timestamp
2. or still, interpret −1 as "no timestamp" and other values as a real timestamp (can we borrow 1 millisecond for our needs?).Add a topic property

Compatibility, Deprecation, and Migration Plan

What impact (if any) will there be on existing users?

If users do not set a record timestamp (producers) or do not care about record timestamp when consuming topic then there will be no impact.

In case existing users do read record timestamp they should be aware of that −1 may mean actual timestamp (or no timestamp depending on the case).

If we are changing behavior how will we phase out the older behavior? 

—

If we need special migration tools, describe them here.

No need if we are not adding field "hasTimestamp" to the message.

When will we remove the existing behavior?

—

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

Topic property:

Add a topic property that says if it may have records with "no timestamp'. That case:

1. users would need to create a new topic and migrate/stream all the records from old topic to the new one
2. users decide what to do with a record without a timestamp: set the timestamp to current or some specific one based on a message content.Solve this with a new message flag

Message flag "hasTimestamp":

1. add a special boolean flag to message record "hasTimestamp",
2. write a migration tool that adds this flag to message with the negative timestamp to legacy messages,
3. make sure clients know about that field and check themThat makes lookup by timestamp a wired thing: .timeindex will not know about these records.

Compatibility, Deprecation, and Migration Plan

What impact (if any) will there be on existing users?

...

If we are changing behavior how will we phase out the older behavior? 

TBD

If we need special migration tools, describe them here.

TBD

When will we remove the existing behavior?

TBD

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

TBD