hi David > I was also considering this solution while we discussed in the jira. It > seems to work in most of the cases but not in all. For instance, let’s > imagine a partition created just before a new consumer joins or rejoins the > group and this consumer gets the new partition. In this case, the consumer > will have a start time which is older than the partition creation time. > This could also happen with the truncation case. It makes the behavior kind > of unpredictable again.
Using a server-side timestamp means comparing the Group Coordinator's time against the Partition Leader's time (which is often a different node). Without strict clock synchronization in Kafka, this "happens-before" relationship remains fundamentally unpredictable. > Instead of relying on a local timestamp, one idea would to rely on a > timestamp provided by the server. For instance, we could define the time > since the group became non-empty. This would define the subscription time > for the consumer group. The downside is that it only works if the consumer > is part of a group. auto.offset.reset is strictly a client-level config. Consumers within the same group can intentionally use different policies. Tying this to a global group state feels like a semantic mismatch. A local timestamp aligns much better, similar to how by_duration operates.
