Dear TZ Coordinators and list members, My name is Dragan Škondrić. I am an independent researcher and the author of *KDS Calendar Version 3.0*, a canon-first calendar-time specification. I am writing with a conceptual and architectural question, not with a request to change the IANA Time Zone Database. The core idea of KDS is that existing civil, legal, metrological, and software time systems — including UTC, Gregorian dates, local time zones, DST rules, ISO 8601 renderings, and TZDB-based local-time projections — may remain as projection-facing systems, while a separate canonical layer preserves invariant event identity. In short: *KDS proposes a canonical event-identity layer above projection-based time systems.* Under this framing, time zones and civil-time rules are not treated as errors or obsolete mechanisms. They remain essential projection systems for human, legal, and operational use. However, they are not treated as the primary identity of a preserved event. The event would instead carry a canonical identity, edition information, annual phase, canonical coordinates, source metadata, and projection profile information, so that different projections can be generated without collapsing the event identity into any one local-time rendering. I am aware that TZDB already solves a very different and highly practical problem: maintaining historical and current civil-time rule data for real-world locations. KDS is not proposed as a replacement for that work. My question is narrower: Does the distinction between *canonical event identity* and *civil/time-zone projection* seem technically meaningful from the perspective of people who maintain or use TZDB? A related question is whether there are existing terms, prior discussions, or known models in the time-zone / civil-time community that already address this separation between: 1. the identity of an event, 2. the instant or time scale used for ordering, 3. the local civil-time rendering, 4. and the future replay of that event under changing time-zone or calendar rules. The specification is archived on Zenodo: *KDS Calendar - Version 3.0* DOI: *10.5281/zenodo.20067725* At this stage I am not asking for endorsement, adoption, or any change to TZDB. I would simply appreciate any technical comments on whether this framing is meaningful, already covered by existing practice, or conceptually misplaced from the viewpoint of the TZDB community. Kind regards, *Dragan Škondrić*