&ND v2 +++document/meta schemaVersion = "1" id = "aeon-gp-temporal-v1" title = "AEON GP Temporal v1" description = "Draft temporal convention for interpreting Core temporal and WTC literals with explicit reference, timescale, timezone database, calendar, clock-realization, smear-provenance, ambiguity, and conflict policy." family = "conventions" group = "General-Purpose Conventions" standing = "official" lifecycle = "draft" normativity = "normative" license = "CC0-1.0" path = "specification/conventions/aeon-gp-temporal-v1" order = 80 publish = true keywords = ["AEON", "temporal", "WTC", "timescale", "UTC", "TAI", "UT1", "TT", "GPS", "timezone", "geographic", "calendar", "leap smear", "clock realization", "ambiguity", "metadata"] related = ["aeon-conventions-overview", "aeon-core-v1-value-types", "appendix-wtc-zone-resolution-v1", "appendix-temporal-ticks-resolution-extent-v1"] +++ # AEON GP Temporal v1 [# aeon-gp-temporal-v1] Convention identifier: [$ aeon.gp.temporal.v1] --- ## 1. Purpose [# purpose] [$ aeon.gp.temporal.v1] defines a standard interpretation vocabulary for AEON temporal literals and the temporal-context payload carried by Core [$ wtc] literals. It applies to ordinary Core temporal literal families such as: - [$ date] - [$ time] - [$ datetime] - [$ wtc] - convention- or profile-defined duration representations The convention separates: | Concern | Responsibility | | <-- | <-- | | Temporal literal form | AEON Core value syntax | | WTC temporal-context form and preservation | AEON Core value syntax | | Temporal interpretation policy | [$ aeon.gp.temporal.v1] metadata | | Materialization and execution | Tonics, profiles, processors, or host runtimes | |~ Temporal convention responsibilities This convention does not extend AEON Core syntax and does not make runtime scheduling, timezone conversion, geographic resolution, or calendar conversion behavior mandatory. Documents using this convention should declare it in the header: ~~~$ aeon aeon:header = { conventions = [ "aeon.gp.temporal.v1" ] } ~~~$ --- ## 2. Design Intent [# design-intent] Modern temporal data often combines several independent concerns: - UTC instants - floating civil times - resolver-local and named-zone times - explicit numeric offsets - scientific, astronomical, and navigation timescales - geopolitical time zones - daylight-saving ambiguity - historical timezone database drift - calendar systems - source clock realization and leap-smear provenance - offset conflict handling - named-zone, named-place, resolver-local, and geographic WTC references [$ aeon.gp.temporal.v1] represents those concerns structurally with metadata rather than overloading timestamp punctuation. Example: ~~~$ aeon meeting@{ target = "zone" zone = "Australia/Melbourne" calendar = "iso8601" tzdbDatum:date = 2026-05-10 tzdbVersion = "2026b" disambiguation = "reject" }:datetime = 2026-06-06T10:10:00 ~~~$ The literal remains an ordinary [$ datetime]; the convention metadata states how a cooperating consumer should interpret it. WTC can instead carry temporal context directly in the Core value: ~~~$ aeon localMeeting:wtc = 2026-06-06T10:10:00&local zonedMeeting:wtc = 2026-06-06T10:10:00+10:00&Australia/Melbourne placeObservation:wtc = 2026-01-01T09:10:00+01:00&+/Antarctica/Elisabeth observedAt:wtc = 2026-06-06T00:10:00Z&-37.8136/144.9631/31 ~~~$ The temporal-value form and temporal-context payload are independent preserved inputs. Resolution and conflict decisions belong to the consumer. ### 2.1 Temporal Contexts [# temporal-contexts] The useful first question is not merely "what time is it?" but "what context anchors this clock reading?" WTC preserves two orthogonal dimensions rather than assigning one meaning to each [$ &] spelling: | Dimension | Forms | | <-- | <-- | | Temporal-value form before [$ &] | unqualified clock reading, explicit numeric offset, or UTC-qualified with [$ Z] | | Temporal context after [$ &] | resolver-selected [$ local], named timezone, named place with [$ +/] prefix, geographic position, or convention-recognized timescale | |~ WTC temporal dimensions The context categories below describe the resulting meaning, not a one-to-one list of WTC suffixes. In particular, [$ &local] is a late-bound resolver-local context and [$ &Australia/Melbourne] is a fixed named-zone context. When either follows an unqualified temporal value, it can provide the rule context for zoned civil time. [$ &local] does not by itself determine whether a value is civil or already identifies an instant; the temporal-value form and field completeness before [$ &] determine that distinction. An unqualified value such as [$ 2027-01-31T23:59:59&local] is a resolver-local civil deadline rather than one global instant. A consumer may resolve it to just before midnight in Melbourne for one subject and just before midnight in Brussels for another. The declaration therefore represents a context-indexed family of possible instants, or a rolling event across local contexts. By contrast, [$ 2027-01-31T23:59:59Z&local] already identifies one UTC instant. The [$ Z] applies to the temporal value before [$ &]: the clock fields are UTC fields, not local civil fields waiting to be converted to UTC. Its [$ &local] context may guide projection or presentation of that fixed instant in the resolver's local timezone, but it does not reinterpret the fields or make the instant float. Under temporal interpretation, [$ 2027-01-31T23:59:59Z&local] and [$ 2027-01-31T23:59:59Z] therefore identify the same instant. They are not the same preserved AEON representation: the WTC form retains the additional [$ local] context, while the ordinary datetime does not. The trusted consumer MUST define what [$ local] selects, such as the subject's current location, an account timezone, or a host environment. It MUST NOT silently substitute the executing machine's timezone when a different resolver-local policy is required by the application. | Context | Question | Example | Consequence | | <-- | <-- | <-- | <-- | | Civil time | What does the clock say? | [$ 20:30] | The unqualified reading floats and does not identify an exact instant. | | Local time (zoned civil time) | Where is the clock? | [$ 20:30] in [$ Australia/Melbourne] | The civil reading is paired with timezone rules, selected through [$ &local], a named zone, or equivalent convention metadata. A date is required and resolution may produce one, multiple, or no instants. Only a successfully resolved result is a zoned instant. | | Offset time | How far is the clock from UTC? | [$ 2026-01-01T20:30:00+10:00] | A complete date, time, and known offset identify one instant, but do not preserve a location or its future and historical rules. | | Universal time | What exact moment is it? | [$ 2026-01-01T10:30:00Z] | A complete UTC-qualified datetime identifies one instant on the global timeline. A time-only or reduced-precision value does not. | | Named-place time | Which identified place is the clock associated with? | [$ 20:30&+/Antarctica/Elisabeth] | The place identity is preserved independently of any timezone rules selected for it. | | Geographic time | Where exactly is the clock located? | [$ 20:30] at [$ -37.8142/144.9631] | Timezone resolution also requires spatial-reference policy; direct geographic use cases include determining the Sun's position for solar panels. | |~ Temporal context distinctions These contexts are not interchangeable. Civil time deliberately lacks enough context to identify an instant. Local time depends on political timezone rules, which can change and which create overlaps or gaps during daylight-saving transitions. A complete date-time with an explicit known offset identifies an instant relative to UTC but cannot guarantee that future or past calculations stay aligned with the wall clock at a location. Geographic time inherits the timezone problem and also depends on a coordinate reference system, coordinate epoch, and the movement of the Earth and its surface. This makes anchoring intent part of the data. If a meeting is planned in Melbourne for 09:00 one month from now and the applicable daylight-saving rules change before then, an application must know whether the meeting was intended to remain at 09:00 in Melbourne or remain attached to the originally resolved global instant. A timescale is a separate concern again: it identifies the time coordinate used for a reading. UTC, TAI, UT1, TT, and GPS time are not interchangeable labels even when a trusted consumer can transform between them. ### 2.2 Anchoring Invariants [# anchoring-invariants] Anchoring applies to every temporal form and context. An anchor names the property that is intended to remain invariant when a value is resolved, converted, projected, or revisited under changed rules or reference data. | Input | Anchor class | Intended invariant | | <-- | <-- | <-- | | unqualified civil fields | field-anchored civil time | authored calendar and clock fields | | [$ &local] | resolver-anchored local context | trusted resolver policy, plus civil fields when the temporal value is unqualified | | named timezone such as [$ &Australia/Melbourne] | zone anchor | named zone identity, plus civil fields when the temporal value is unqualified | | explicit known numeric offset other than [$ -00:00] | offset anchor | authored numeric relationship to UTC; an exact instant only when date and clock fields are complete | | [$ -00:00] | unknown-offset claim | authored statement that the local offset is unknown or unspecified; no instant follows from the offset alone | | uppercase [$ Z] or convention-recognized [$ &UTC] | UTC anchor | authored UTC coordinate; a global instant only when date and clock fields are complete | | named place such as [$ &+/Antarctica/Elisabeth] | place anchor | exact authored place context, independent of any same-spelled timezone identifier | | geographic position | geographic anchor | authored coordinates and their spatial-reference metadata, plus civil fields when unqualified | | [$ &TAI], [$ &UT1], [$ &TT], [$ &GPS], or [$ timescale] metadata | timescale anchor | authored time coordinate and timescale identity | |~ Temporal anchor classes Temporal forms and contexts compose, so one WTC value may carry more than one anchor: | Form | Recommended name | Preserved anchor | Effect of changed timezone rules | | <-- | <-- | <-- | <-- | | [$ 2027-01-31T23:59:59&Australia/Melbourne] | zone-anchored zoned civil time | Melbourne zone identity and authored civil clock fields | Keep Melbourne civil time; authority assessment, mapping cardinality, or derived candidates may change. | | [$ 2027-01-31T23:59:59Z&Australia/Melbourne] | instant-anchored zoned instant claim | authored UTC coordinate and Melbourne context | Keep the UTC instant anchor; under the same authority and clock-realization model, the projected Melbourne civil time may change without changing the resulting instant. | | [$ 2027-01-31T23:59:59+11:00&Australia/Melbourne] | dual-anchored zoned-instant claim | Exact instant, authored offset, civil fields, and Melbourne context | If later rules disagree with the authored offset or civil projection, expose a conflict rather than silently changing an anchor. | |~ Composed temporal anchoring examples These names describe interpretation intent, not new Core value kinds. AEON Core preserves every component but does not determine whether a named zone exists, whether an offset agrees with its rules, which timezone database release applies, whether a geographic position selects a civil-time jurisdiction, whether a timescale conversion is authoritative, or whether a zoned civil time resolves uniquely. A temporal-aware consumer establishes those results under trusted policy. If [$ tzdbVersion], coordinate reference metadata, timescale realization data, or equivalent trusted configuration pins the required reference inputs, interpretation can remain reproducible. The change behavior above applies when the value is deliberately resolved, converted, or projected using different reference data. ### 2.3 UTC and Zero-Offset Claims [# utc-and-zero-offset-claims] This convention distinguishes three zero-offset-looking forms: | Form | Convention meaning | | <-- | <-- | | [$ Z] | explicit UTC anchor | | [$ +00:00] | explicit known numeric zero-offset anchor | | [$ -00:00] | local offset is unknown or unspecified, following RFC 3339 | |~ UTC and zero-offset distinctions [$ Z] and [$ +00:00] may resolve to the same instant, but they remain distinct authored representations and provenance claims. [$ -00:00] does not supply a known zero offset and does not by itself identify an instant. A consumer MUST preserve the minus sign and MUST NOT normalize [$ -00:00] to [$ Z] or [$ +00:00]. A profile or Tonic unable to preserve the unknown-offset distinction MUST reject the value. An authored instant anchor is not an authority-backed resolved instant. Lexical [$ Z] asserts a UTC anchor but does not prove that the source clock was aligned exactly with unsmeared UTC. A confirmed leap second may also be projected through a known numeric offset or named zone, so the same instant can carry second [$ 60] at a local hour, minute, or date other than UTC [$ 23:59] on the announced UTC date. A named-zone context does not override [$ -00:00]. For example, [$ 2026-01-01T09:10:10-00:00&Australia/Melbourne] preserves both an unknown-offset claim and a Melbourne-zone claim. A downstream consumer may validate the civil fields against selected Melbourne rules, but it MUST NOT infer and substitute a known numeric offset or a particular daylight-saving branch merely from the zone. A result requiring one exact offset or instant remains unresolved unless explicit trusted policy supplies and records the missing knowledge. ### 2.4 Named-Place Contexts [# named-place-contexts] This convention reserves an exact leading [$ +/] inside a WTC temporal-context payload to identify a named place rather than a timezone ruleset: ~~~$ text &+/Antarctica/Elisabeth named place &Antarctica/Elisabeth ordinary named context, including a timezone if recognized as one ~~~$ The distinction is permanent and representation-significant. If [$ Antarctica/Elisabeth] later becomes an IANA timezone identifier, [$ &+/Antarctica/Elisabeth] remains a place context and [$ &Antarctica/Elisabeth] may resolve as the timezone. A canonicalizer MUST NOT add or remove [$ +/] merely because a place and timezone currently select the same rules. The portion after [$ +/] is a non-empty slash-separated place path. Core preserves it as an ordinary valid WTC context payload. This convention assigns the prefix its category; it does not make the path globally unique or authoritative. A place context does not inherently select a timezone, coordinate, jurisdiction, or instant. AEON Core, AES, AEOS, temporal profiles, schemas, and convention validators MUST NOT attempt to validate that the place exists or assign temporal meaning to it. They validate and preserve only the WTC representation and the convention-defined [$ +/] category. Place identity and place-to-time association belong to the downstream domain consumer. For an unqualified temporal value, that consumer may use its own registry, effective-date rules, coordinates, or application policy to associate the place with local-time rules. Until then, the value remains civil fields anchored to an unresolved place. A value already carrying [$ Z] or a known numeric offset is already instant-anchored, so the place remains additional context and no place-to-time resolution is required to establish that anchor. ### 2.5 WTC Context Classification Precedence [# wtc-context-classification] A convention-aware classifier applies the following precedence without guessing from a slash-shaped name: 1. exact lowercase [$ local]; 2. the exact uppercase recognized timescales [$ UTC], [$ TAI], [$ UT1], [$ TT], and [$ GPS]; 3. the exact [$ +/] named-place discriminator; 4. a complete geographic component form; 5. an exact timezone identifier confirmed by the trusted timezone authority; 6. another explicitly registered convention context; 7. [$ unresolved]. A payload such as [$ Area/Location] is not proven to be a timezone merely because it resembles an IANA name. If the selected timezone authority does not recognize it, classification remains [$ unresolved]. A classifier MUST retain the original payload and MUST NOT fall through to a more convenient category after an authority lookup fails. ### 2.6 Reduced Precision, Temporal Ticks, and Relations [# reduced-precision-and-relations] Omitted minute or second fields are unasserted subordinate fields, not implicit zeroes or inherently unknown measurements. A reduced-precision value is one exact temporal tick at its authored granularity. When refined into a finer temporal domain, its tick extent is the set of fully specified temporal coordinates compatible with the authored fields. Within an otherwise selected UTC date: ~~~$ text 10:Z -> [10:00:00, 11:00:00) 10:30Z -> [10:30:00, 10:31:00) ~~~$ A time-only value does not supply that date. It remains a recurring time-of-day constraint and is not comparable with a dated instant unless trusted consumer policy supplies the missing date and admits cross-category comparison. Temporal tick, granularity, refinement, extent, exact coordinate, and instant are defined in [@ document:appendix-temporal-ticks-resolution-extent-v1 | the temporal-ticks appendix]. Tick extent describes semantic breadth at a finer granularity; it is not measurement uncertainty. Selecting [$ 10:00:00] as the lower boundary of [$ 10:Z] is an explicit boundary-selection operation rather than an identity-preserving zero fill. When seconds are explicitly present, an omitted fractional part means an exact zero fractional coefficient. This preserves the existing relationship in which [$ 10:30:00.34Z] is 340 milliseconds after [$ 10:30:00Z]. Measurement uncertainty is separate metadata and is not inferred from omitted fields or fractional digit count. Temporal semantic equality requires identical completion sets in the selected comparison domain; mere overlap is not equality. It is separate from representation equality and resolved-result equality. Thus differently scaled spellings such as [$ .34] and [$ .340] can be temporally semantically equal while remaining representation-distinct. A precision-aware resolver should distinguish at least [$ equal], [$ before], [$ after], [$ contains], [$ containedBy], [$ overlaps], and [$ incomparable]. Consequently, [$ 10:Z] contains [$ 10:30Z], but the values are not equal and neither is temporally before or after the other. SANSA queries, indexes, and profiles must identify which equality domain they use. Deterministic serialization or index order is separate from temporal ordering. A profile may select broader-first, narrower-first, lower-bound-first, or canonical-payload order, but it MUST identify that policy and MUST NOT present containment as chronology. ### 2.7 Admission, Authority Assessment, and Mapping [# admission-authority-and-mapping] Temporal processing reports separate dimensions: | Dimension | Outcomes | | <-- | <-- | | profile status | [$ admitted], [$ rejected] | | authority assessment | [$ confirmed], [$ contradicted], [$ unresolved] | | mapping cardinality | [$ zero], [$ one], [$ many], [$ unresolved] | |~ Temporal processing dimensions A timezone overlap can be admitted and confirmed while mapping to many candidates. A timezone gap can be admitted and confirmed while mapping to zero. A future leap claim can be admitted while its authority assessment and mapping remain unresolved. Profile rejection occurs before authority-backed mapping. Selection or transformation follows mapping. [$ earlier] and [$ later] select actual candidates after a [$ many] result. A [$ zero] result has no candidate to select and requires a separately declared gap-materialization policy if the consumer does not preserve or reject it. --- ## 3. Scope [# scope] This convention defines temporal interpretation metadata and common structured calendar-date objects. It does not define: - new Core temporal literal syntax - a new Core [$ duration] literal - timezone database contents - canonical temporal serialization - runtime scheduling behavior - host-language temporal object materialization - timezone or geographic-reference resolution - authoritative named-place registry contents or place-to-timezone resolution - civil-time jurisdiction selection from coordinates - geodetic transformation - authoritative timescale realization or conversion data - leap-smear algorithms or trusted destination-clock policy Consumers that do not understand this convention should preserve the attributes as ordinary AEON metadata or fail according to their convention-adoption policy. AEON Core and its parser preserve the text after [$ &] without classifying it as a runtime subtype. Terms such as "dispatch" therefore do not describe parser behavior here. A convention-aware consumer may classify a preserved context as exact [$ local], a [$ +/] named place, geographic coordinates, a recognized timescale, a recognized timezone, or an unresolved named context. The precedence between categories is convention-level interpretation and must retain an unresolved outcome when the consumer lacks required knowledge. --- ## 4. Fields [# fields] The following attribute keys are defined by [$ aeon.gp.temporal.v1]. ### 4.1 [$ target] [# target] [$ target] identifies the intended temporal interpretation mode for temporal values that do not already carry an intrinsic WTC reference. Allowed values: | Value | Meaning | | <-- | <-- | | [$ "utc"] | Interpret as a universal instant | | [$ "civil"] | Interpret as a floating civil time without a timezone | | [$ "local"] | Interpret as zoned civil time using timezone rules selected by trusted resolver policy or other convention metadata | | [$ "zone"] | Interpret as zoned civil time in the named [$ zone] | |~ Temporal target values Examples: ~~~$ aeon created@{ target = "utc" }:datetime = 2026-06-06T10:10:00Z ~~~$ ~~~$ aeon alarm@{ target = "civil" }:datetime = 2026-06-06T09:00:00 ~~~$ ~~~$ aeon localAlarm@{ target = "local" disambiguation = "reject" }:datetime = 2026-06-06T09:00:00 ~~~$ ~~~$ aeon meeting@{ target = "zone" zone = "Australia/Melbourne" }:datetime = 2026-06-06T10:10:00 ~~~$ These [$ target] values are interpretation metadata, not spellings for the text after [$ &]. In particular, [$ target = "local"] does not require the intrinsic context [$ &local]; a named [$ zone] can also provide the rules for zoned civil time. For [$ wtc], the intrinsic reference remains authoritative input. Consumers MUST NOT silently replace it with [$ target] metadata. ### 4.2 [$ zone] [# zone] [$ zone] identifies an authoritative regional timezone supplied as metadata. ~~~$ aeon zone = "Australia/Melbourne" ~~~$ Rules: - values SHOULD be IANA timezone database identifiers; - consumers applying [$ zone] MUST fail if the zone is unknown; - consumers MUST NOT silently substitute an equivalent or nearby zone. When a [$ wtc] literal also carries a temporal context, any disagreement between [$ zone] and that context is a conflict governed by the consumer's [$ conflictAuthority] policy. ### 4.3 [$ calendar] [# calendar] [$ calendar] identifies the calendar system used to interpret the temporal value. Examples: ~~~$ aeon calendar = "iso8601" calendar = "gregorian" calendar = "japanese" calendar = "hebrew" ~~~$ If omitted, consumers MAY assume [$ iso8601]. A profile or schema MAY require explicit calendar metadata. ### 4.4 [$ tzdbDatum] [# tzdbdatum] [$ tzdbDatum] records the date of timezone database assumptions used by the producer. ~~~$ aeon tzdbDatum:date = 2026-05-10 ~~~$ This field improves reproducibility and helps future processors detect possible timezone rule drift. It does not pin an exact timezone database version. ### 4.5 [$ tzdbVersion] [# tzdbversion] [$ tzdbVersion] records the timezone database release identifier used by the producer. ~~~$ aeon tzdbVersion = "2026b" ~~~$ Values SHOULD use IANA Time Zone Database release labels when the producer can identify the source rule set. This field improves reproducibility when timezone rules change after the document is produced. ### 4.6 [$ disambiguation] and [$ gapPolicy] [# disambiguation] [$ disambiguation] states how a [$ many]-candidate zoned civil mapping should be handled. Allowed values: | Value | Meaning | | <-- | <-- | | [$ "earlier"] | Choose the earlier existing candidate | | [$ "later"] | Choose the later existing candidate | | [$ "reject"] | Reject selection from the ambiguous mapping | | [$ "preserve"] | Preserve the candidates without selecting one | |~ Temporal disambiguation values [$ gapPolicy] states what a materializer may do after mapping returns [$ zero] candidates: | Value | Meaning | | <-- | <-- | | [$ "reject"] | Refuse to materialize the gap | | [$ "null"] | Produce a reason-bearing typed null | | [$ "previousValid"] | Explicitly transform to the nearest valid target coordinate before the gap | | [$ "nextValid"] | Explicitly transform to the nearest valid target coordinate after the gap | | [$ "preserveClaim"] | Preserve the authored claim without manufacturing a coordinate | |~ Temporal gap-materialization values Gap materialization is not resolution of the authored claim. [$ previousValid] and [$ nextValid] produce different coordinates and must be reported as explicit transformations. Duration-preserving shifts across a gap, if later admitted, require distinct policy names and are not implied by these boundary-selection policies. [$ earlier] and [$ later] are reserved for selecting among existing candidates after a [$ many] mapping. They do not apply to a [$ zero]-candidate gap. The full named-zone mapping and policy model is consolidated in [@ document:appendix-wtc-zone-resolution-v1 | the WTC zone-resolution appendix]. Example: ~~~$ aeon event@{ target = "zone" zone = "Australia/Melbourne" disambiguation = "reject" }:datetime = 2025-04-06T02:30:00 ~~~$ A gap policy is separate: ~~~$ aeon skipped@{ target = "zone" zone = "Australia/Melbourne" gapPolicy = "preserveClaim" }:datetime = 2025-10-05T02:30:00 ~~~$ ### 4.7 [$ offset] [# offset] [$ offset] records an offset associated with the value. ~~~$ aeon offset = "+10:00" ~~~$ This field is informational unless another selected profile, schema, or tonic defines stronger behavior. An explicit numeric offset or [$ Z] embedded in a [$ wtc] temporal value is intrinsic representation, not this metadata field. A disagreement between intrinsic and supplemental offset inputs is governed by the consumer's [$ conflictAuthority] policy. The Core structural offset range is not a timeless registry of offsets used by civil jurisdictions. This convention does not narrow it by predicting which offsets can occur. Agreement between a numeric offset, date, civil fields, named timezone, and selected timezone-database release is checked by the downstream consumer. ### 4.8 [$ timescale] [# timescale] [$ timescale] identifies the time coordinate used by a temporal value independently of its timezone, offset, calendar, or geographic context. Initial recognized values use the exact uppercase spellings below: | Value | Meaning | | <-- | <-- | | [$ "UTC"] | Coordinated Universal Time, the international reference timescale and basis of civil time in most countries | | [$ "TAI"] | International Atomic Time, a continuous atomic timescale produced by the BIPM | | [$ "UT1"] | Universal Time determined from the observed rotation of the Earth | | [$ "TT"] | Terrestrial Time, the idealized terrestrial coordinate timescale used in astronomy and geodesy | | [$ "GPS"] | GPS Time, the continuous atomic timescale used by the Global Positioning System | |~ Recognized timescales Example metadata on an ordinary datetime: ~~~$ aeon observation@{ timescale = "TT" }:datetime = 2026-01-01T09:10:10 ~~~$ The same identifiers may be carried intrinsically as WTC temporal contexts: ~~~$ aeon coordinated:wtc = 2026-01-01T09:10:10&UTC tai:wtc = 2026-01-01T09:10:10&TAI earthRotation:wtc = 2026-01-01T09:10:10&UT1 terrestrial:wtc = 2026-01-01T09:10:10&TT navigation:wtc = 2026-01-01T09:10:10&GPS ~~~$ AEON Core already accepts and preserves these as ordinary named WTC references. This convention assigns them timescale meaning; it does not add literal syntax. An intrinsic [$ Z] designator or [$ target = "utc"] declares UTC. A known numeric offset is also UTC-relative. An intrinsic recognized timescale reference declares its named timescale. A [$ Z] or known-offset value combined with a non-UTC recognized timescale is not one coherent general-purpose temporal claim. For example, [$ 2026-01-01T09:10:10Z&TAI] and [$ 2026-01-01T09:10:10+01:00&TAI] are structurally preserved by Core but MUST be rejected by the general-purpose temporal schema or a convention-aware validator. Preservation-only processors may retain the conflicting claims; they MUST NOT resolve them as one instant. Supplemental [$ timescale] metadata MUST agree with intrinsic or target declarations. Trusted conflict policy may choose which claim to retain for a separate transformation, but it does not make the original contradictory combination semantically valid. A timescale identifier alone does not select a particular laboratory realization, Earth-orientation data release, prediction series, or conversion algorithm. Authoritative conversion can require external BIPM, IERS, or navigation-system data and remains consumer policy. Consumers MUST NOT treat the scales as aliases or silently relabel a reading without performing a defined conversion. ### 4.9 [$ clockModel] [# clockmodel] [$ clockModel] identifies how the clock that produced the authored fields relates to the declared or intrinsic timescale. It records source provenance; it does not instruct a consumer which clock model to use when materializing an output. Allowed values: | Value | Meaning | | <-- | <-- | | [$ "direct"] | The producer claims a direct realization of the declared or intrinsic timescale, without a leap smear | | [$ "posix"] | The producer used a POSIX-style clock model that does not represent leap seconds as distinct second-[$ 60] values | | [$ "smear"] | The producer distributed a leap adjustment over an interval according to [$ smearPolicy] | |~ Source clock models Omission makes no additional clock-realization claim. A consumer requiring exact physical-time conversion MAY require this field and supporting authority data. A lexical UTC marker and clock realization are independent claims. A [$ Z]-qualified value with [$ clockModel = "smear"] carries nominal UTC fields produced by a smeared clock; during the smear interval it is not necessarily aligned with true UTC. This is an explicit qualification of the lexical UTC claim rather than permission to silently reinterpret every [$ Z] value. Example: ~~~$ aeon receivedAt@{ timescale = "UTC" clockModel = "smear" smearPolicy = "google" }:datetime = 2026-01-01T09:10:10Z ~~~$ Rejecting literal second [$ 60] does not imply [$ clockModel = "direct"]. A profile may admit only [$ 00-59] seconds and still receive POSIX-derived or smeared readings. ### 4.10 [$ smearPolicy] [# smearpolicy] [$ smearPolicy] identifies the algorithm and policy under which a smeared source reading was produced. Rules: - [$ smearPolicy] is REQUIRED when [$ clockModel = "smear"] and exact conversion is requested; - the identifier uses a stable namespace and algorithm name, for example [$ google:linear-24h]; - algorithm version, adjustment sign, and effective interval are separate authority fields and MUST NOT be hidden inside an unparseable display label; - a provider-family identifier such as [$ "google"] alone is incomplete for exact conversion; - document-provided policy text is a claim, not trusted executable conversion authority; - a consumer that lacks the named policy or required interval data MUST preserve the value as unresolved or reject exact conversion. Source and destination policy are deliberately separate. These attributes are authored claims about the source value. They remain opaque to Core and do not grant execution authority. A downstream Tonic or materializer explicitly selects trusted source configuration, authority data, and destination clock policy. Positive-leap export uses a separately declared policy such as [$ reject], [$ foldPrevious], [$ foldNext], [$ clampDown], [$ clampUp], or [$ smear], with [$ preserve] available for a leap-aware target. An authority-declared negative leap gap first maps to [$ zero] candidates; subsequent materialization uses [$ reject], [$ null], [$ previousValid], [$ nextValid], or [$ preserveClaim]. Import and export policies are declared separately. When source and destination models differ, the Tonic MUST perform the selected defined transformation, explicitly preserve semantic uncertainty or loss, or reject the mapping. ### 4.11 Authority References [# authority-references] Trusted resolver configuration and recorded resolution provenance use a common authority-reference shape: ~~~$ aeon authority = { kind = "tzdb" id = "iana:tzdb" version = "2025b" retrievedAt:datetime = 2026-09-28T00:00:00Z effectiveFrom:date = 2025-01-01 effectiveThrough:date = 2025-12-31 } ~~~$ [$ kind] initially admits [$ leapSeconds], [$ tzdb], [$ clockRealization], [$ calendar], [$ coordinates], and [$ smear]. [$ id] names the authority or algorithm family; [$ version] selects an exact data or algorithm release; [$ retrievedAt] records acquisition provenance; and the effective bounds state coverage when known. UT1 and observational calendar authorities use the same shape even when their version vocabulary is domain-specific. Missing required authority fields produce an unresolved assessment, not an inferred current version. Document-carried authority objects are provenance claims. Only a trusted consumer registry or host configuration can authorize their contents for resolution. ### 4.12 [$ apply] [# apply] [$ apply] lists target projection zones for display or transformation workflows. ~~~$ aeon apply = [ "Australia/Perth" "Europe/Paris" ] ~~~$ This field does not define execution semantics. ## 5. Calendar-Native Convention Objects [# calendar-native-convention-objects] The convention defines [$ calendarDate] and [$ calendarDateTime] as structured custom-datatype vocabularies. They are ordinary Core objects, not new literal kinds, and their base meaning does not require a profile. A common month-based date uses: ~~~$ aeon date:calendarDate = { calendar:string = "hebrew" year:int = 5779 monthCode:string = "M05L" day:int = 23 } ~~~$ A common calendar-native datetime adds a civil [$ time]: ~~~$ aeon date:calendarDateTime = { calendar:string = "gregory" year:int = 2029 monthCode:string = "M01" month:int = 1 day:int = 19 time:time = 23:00:01 } ~~~$ Common fields are: | Field | Convention role | | <-- | <-- | | [$ calendar] | Required calendar or algorithm identifier | | [$ year] | Required calendar-native arithmetic year | | [$ monthCode] | Stable month identity for month-based calendars, including leap-month codes such as [$ M05L] | | [$ day] | Calendar-native day within the identified month | | [$ era] and [$ eraYear] | Conditional fields when the calendar requires an era representation | | [$ month] | Optional ordinal within this particular year; it does not replace [$ monthCode] | | [$ monthName] | Optional localized presentation data; it is not authoritative | | [$ time] | Required on [$ calendarDateTime]; a Core civil time-of-day | |~ Common calendar object fields Redundant fields are independent claims and must agree when a calendar-aware downstream consumer validates them. The object by itself supplies no timezone, offset, timescale, or instant. This vocabulary covers common interoperable cases and is intentionally non-exhaustive. Calendars based on weeks, cycles, seasons, observations, or other field models may require additional convention-defined structures or authority metadata. A schema may impose narrower application requirements, but this convention is not elevated into a mandatory temporal profile. A clarifier form such as [$ calendarDateTime\["gregory"\]] is not assigned meaning here. It requires a separately adopted profile that allows that clarifier on an object and defines its equivalence to the explicit [$ calendar] field. ## 6. Consumer Conflict Policy [# consumer-conflict-policy] [$ conflictAuthority] is a consumer policy for handling inconsistent temporal inputs. It is not an AEON attribute defined by this convention and is not document-controlled execution authority. Allowed values: | Value | Meaning | | <-- | <-- | | [$ "reject"] | Reject inconsistent inputs. | | [$ "temporal"] | Treat the temporal value, including an intrinsic offset or [$ Z], as authoritative. | | [$ "reference"] | Treat the WTC temporal context or convention metadata selected by the consumer as authoritative. | | [$ "preserve"] | Preserve the conflict without resolving it. | |~ Temporal conflict-authority values A consumer performing authoritative temporal resolution MUST default to [$ "reject"] unless trusted host, profile, schema, or runtime configuration selects another value. Parsing, canonicalization, forwarding, and other preservation-only operations MAY retain conflicting inputs without selecting an authority. An arbitrary document MUST NOT grant itself conflict-resolution authority merely by carrying an attribute with this name. For an unqualified [$ datetime&Zone] WTC claim, the named zone and local civil fields provide the zone anchor and there is no competing intrinsic instant anchor. A [$ datetime+hh:mm&Zone] claim is dual-anchored: the known offset derives an instant while the zone maps the local civil fields, and disagreement is a conflict governed by this policy. A [$ datetimeZ&Zone] claim is instant-anchored: [$ Z] qualifies the preceding fields as UTC, while the zone supplies projection context and MUST NOT cause those fields to be reinterpreted as zone-local time. A known offset may select an existing overlap candidate, but it cannot manufacture a candidate during a gap. --- ## 7. Fail-Closed Guidance [# fail-closed-guidance] Consumers applying this convention SHOULD fail when: - timezone identifiers are unknown; - a downstream domain consumer is asked to produce an authoritative local-time result for an unknown or ambiguous [$ &+/...] place identifier; - an ambiguous [$ many]-candidate zoned civil mapping violates the selected disambiguation policy; - a [$ zero]-candidate gap is transformed without an admitted and visible [$ gapPolicy]; - timescale identifiers are unknown or unsupported; - authoritative timescale resolution requires data the consumer does not have; - exact conversion of a smeared value requires an unknown smear policy or unavailable interval data; - a profile requires direct timescale realization but the value declares [$ clockModel = "posix"] or [$ clockModel = "smear"]; - required metadata is missing; - calendar systems are unsupported; - temporal inputs conflict under [$ conflictAuthority = "reject"]. Consumers MUST NOT silently reinterpret temporal intent. A structurally valid unknown-offset claim is not itself an invalid datetime. If downstream materialization cannot produce a Core-representable temporal value, the consumer may return a typed null such as [$ result:null = !"unrepresentable temporal coordinate"], preserve opaque source data, or use another explicitly adopted structured representation. It MUST NOT synthesize a malformed temporal literal. --- ## 8. Relationship to Core Temporal Types [# relationship-to-core-temporal-types] AEON Core v1 owns the literal syntax for [$ date], [$ time], [$ datetime], and [$ wtc]. [$ aeon.gp.temporal.v1] does not change those literal forms. It defines shared interpretation defaults around them. The general-purpose admitted domain restricts the seconds field to [$ 00-59] and fractional seconds to at most nine authored digits. The draft [$ 0.14.0] implementation expands Core structural recognition to second [$ 60] and preserves arbitrary fractional precision, while the general-purpose schema artifact applies [$ temporal_max_second] and [$ temporal_max_fraction_digits] through SANSA representation-kind selectors so typed and untyped temporal literals receive the same policy. Violations use the [$ temporal_field_constraint_mismatch] diagnostic. Its [$ temporal_context_policy] constraint also rejects known UTC-relative anchors combined with recognized non-UTC timescales. A specialized leap-aware or higher-precision profile and schema may widen those limits under separately declared authority and resolution requirements. A Core [$ wtc] value is a temporal value followed by [$ &] and a temporal context. The reserved resolver-local context is exactly lowercase [$ local]; case variants such as [$ Local] and [$ LOCAL] are invalid. Other named contexts retain their authored case. WTC preserves three temporal-value forms independently of the reference after [$ &]: - unqualified: no offset designator, for example [$ 2026-06-06T10:10:00&local] or [$ 2026-01-01T09:10:10&TAI]; - offset-qualified: an explicit numeric offset, for example [$ 2026-06-06T10:10:00+10:00&Australia/Melbourne], including the distinct unknown-offset marker [$ -00:00]; - UTC-qualified: uppercase [$ Z], for example [$ 2026-06-06T00:10:00Z&Australia/Melbourne]. UTC-qualified forms and offset-qualified forms carrying a known numeric offset provide an instant anchor when their date and clock fields are complete, but they remain lexically distinct and MUST NOT be rewritten merely because they resolve to the same instant. Reduced-precision forms preserve completion sets rather than silently zero-filling omitted fields. Time-only forms still lack a date. The offset form [$ -00:00] is a separate exception: it records an unknown or unspecified offset and does not identify an instant from the offset alone. A WTC temporal context may be: - exact lowercase [$ local]; - a named timezone such as [$ Australia/Melbourne]; - a named place beginning with the exact prefix [$ +/], such as [$ +/Antarctica/Elisabeth]; - a timescale recognized by this convention: [$ UTC], [$ TAI], [$ UT1], [$ TT], or [$ GPS]; - a geographic position in [$ latitude/longitude] or [$ latitude/longitude/height] component order. Timescale contexts are lexically ordinary named contexts in AEON Core. Their interpretation is supplied by this convention and does not require parser branching or a new AES value kind. Because convention interpretation is downstream, Core acceptance of [$ Z&TAI], a known numeric offset with [$ &TAI], or any other named combination is only structural preservation. The general-purpose temporal schema and convention-aware consumers enforce the incompatibility rules above. Named-place contexts are also lexically ordinary WTC contexts in Core. The [$ +/] prefix is a convention-defined semantic discriminator and does not require a new Core token or AES value kind. Processors applying this convention MUST preserve it exactly. Core preserves geographic component payloads without supplying a coordinate reference system. When this convention is actively adopted, and unless a stricter trusted profile overrides the interpretation, the convention explicitly interprets those components as WGS 84 latitude and longitude in decimal degrees and optional WGS 84 ellipsoidal height in metres. Core does not validate coordinate ranges, perform geodetic resolution, or select a civil-time jurisdiction. Precision-sensitive uses may require explicit coordinate reference system, datum, coordinate epoch, and vertical-reference metadata through a separate spatial convention or profile. Parsers, canonicalizers, and preservation-only processors MUST preserve both the authored temporal-value form and the temporal-context payload, including the distinction between [$ Z], [$ +00:00], and [$ -00:00]. Consumers may interpret or resolve them only under an explicit policy. Duration semantics remain outside AEON Core v1. When duration-like values are needed, they are schema-, profile-, convention-, or consumer-defined. --- ## 9. Relationship to Future [$ zdt] [# relationship-to-future-zdt] The datatype label [$ zdt] is reserved for a possible future zoned datetime type. [$ zdt] is not operational in AEON Core v1. This convention does not require processors to accept [$ :zdt], and it does not define bracketed zoned-datetime lexical syntax. Future AEON versions or profiles may define a transport-oriented [$ zdt] type. It would not replace Core [$ wtc] or authorize rewriting preserved WTC forms. The temporal convention remains orthogonal to that possibility because it represents timezone, calendar, ambiguity, and projection metadata structurally. Possible future example: ~~~$ aeon created:zdt = 2025-01-01T12:00:00+11:00[Australia/Melbourne][u-ca=japanese] ~~~$ The example above is reserved future syntax, not AEON Core v1 syntax. --- ## 10. Related Standards [# related-standards] This convention is conceptually compatible with: - RFC 3339 - RFC 9557 - BIPM CCTF Recommendation 3 (2017) definitions of TAI and UTC - IAU 2000 Resolutions B1.8 and B1.9 definitions of UT1 and TT - IERS Earth-orientation products and conventions - IS-GPS-200 definition of GPS Time - Java [$ ZonedDateTime] - JavaScript [$ Temporal] It does not require AEON Core to adopt bracketed zone annotations, inline calendar annotations, or any specific host-runtime temporal object model.