Dear Tim, Thank you for taking the time to read and respond. Your reply is very helpful, and I think it shows that my use of the phrase canonical event identity was not precise enough for this context.
I agree that UTC, together with TZDB, already handles civil instants, ordering, and local-time rendering very well. I also agree that specialized scientific timescales such as TAI, TT, and Julian day counts already serve many scientific and astronomical use cases. KDS is not intended to replace those systems. The distinction I was trying to express is this: A timestamp identifies an instant. A KDS event identity identifies a persisted event record. In other words, the timestamp remains one component of the record, but it is not the whole identity of the preserved event. In the KDS model, the identity preimage also includes source namespace, source event key, source timescale, edition identifier, projection profile, canonical coordinate data, and payload hash. A simple example would be two independent systems producing records at the exact same UTC instant. For ordering purposes, UTC may be sufficient. For identity purposes, those are not necessarily the same event. KDS would treat them as distinct unless the source identity, payload hash, edition, and projection profile also match. Conversely, one preserved event may have multiple local-time or legal renderings over time, but still retain one invariant record identity. So I now see that the relevant question is probably not a TZDB question in the narrow sense. TZDB already provides the civil-time projection layer. The KDS question is more about whether long-term preservation, provenance, or event-record systems need a formal identity and replay envelope around the timestamp and its projections. Your response helps clarify that I should not frame KDS as a replacement or correction of UTC/TZDB practice. A better framing is: KDS treats UTC/TZDB as projection and ordering infrastructure, while defining an additional canonical identity envelope for preserved event records. I appreciate your comments and the references to the TZDB theory file. I will revise my wording accordingly and direct the preservation/provenance aspects of the work toward communities better positioned to evaluate that part of the model. Kind regards, Dragan Škondrić On Tue, 26 May 2026, 23:50 Tim Parenti, <[email protected]> wrote: > > On Tue, 26 May 2026 at 14:08, Dragan Škondrić via tz <[email protected]> wrote: > >> 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? >> > I'm struggling to conceptualize what precisely you mean by "canonical > event identity" that wouldn't already handled by a timestamp expressed > either in UTC or in one of many specialized scientific timescales already > in use. > >> 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. >> >> It is unclear what your perceived distinction between (1) and (2) is. Do > bear in mind that readers of this mailing list come from a wide array of > disciplines, so we may not be well-versed in technical jargon outside our > immediate remit of civil timekeeping. But for these broad purposes, where > relativistic and quantum effects are negligible, events' timestamps are > simply governed by their natural ordering to whatever precision is > available or desired. > > So (1) and (2) are assuredly quite well-handled for civil purposes by UTC > (and its predecessor timescales like UT/GMT), and (3) and (4) are handled > by UTC in combination with TZDB. Our approach to calendar rules is to > adopt the proleptic Gregorian calendar; see: > https://data.iana.org/time-zones/data/theory.html#calendar > > Certain scientific applications, particularly pertaining to astronomy, may > prefer other timescales like TAI or Terrestrial Time (TT), or even Julian > day counts based on TT — along with leap-second corrections and updated > ephemerides, these can be mapped onto UTC directly for the past and as > approximations with diminishing accuracy into the far future. There are, > of course, more advanced and specialized applications for which the effects > of relativistic time dilation or quantum ordering are more significant. I > would presume these would tend to have their own systems in place for > grappling with the resulting timescales, as needs seem quite likely to vary > significantly; I am not aware of any broadly-adopted framework that seeks > to unify varying project-specific approaches. > >> 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. >> > I glanced through the specification, and found that much of it hinges on > calendar and timescale reform proposals that are firmly out-of-scope for > TZDB's work and which I would expect would remain so even if adopted for a > specific purpose within a scientific community; see: > https://data.iana.org/time-zones/data/theory.html#planets > > I can't say for sure whether your proposed framing is "meaningful" or > "misplaced" without better understanding the concrete shortcomings you feel > existing practice may have. My sense, however, is that most potential > concerns are already covered across a disparate array of sub-disciplines > within the scientific community, albeit in domain-specific ways. In any > case, depending on your goals, I suspect researchers within the relevant > disciplines may be better positioned than we are here to evaluate your > framing's utility, novelty, or completeness. > > -- > Tim Parenti > >>
