AEON GP Temporal v1

Convention identifier: aeon.gp.temporal.v1

1. 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:

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:header = {
  conventions = [
    "aeon.gp.temporal.v1"
  ]
}

2. 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:

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:

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

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:

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.

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 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.

Temporal forms and contexts compose, so one WTC value may carry more than one anchor:

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

This convention distinguishes three zero-offset-looking forms:

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

This convention reserves an exact leading +/ inside a WTC temporal-context payload to identify a named place rather than a timezone ruleset:

&+/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

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

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:

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 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

Temporal processing reports separate 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

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

The following attribute keys are defined by aeon.gp.temporal.v1.

4.1 target

target identifies the intended temporal interpretation mode for temporal values that do not already carry an intrinsic WTC reference.

Allowed values:

Examples:

created@{
  target = "utc"
}:datetime = 2026-06-06T10:10:00Z

alarm@{
  target = "civil"
}:datetime = 2026-06-06T09:00:00

localAlarm@{
  target = "local"
  disambiguation = "reject"
}:datetime = 2026-06-06T09:00:00

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 identifies an authoritative regional timezone supplied as metadata.

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 identifies the calendar system used to interpret the temporal value.

Examples:

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 records the date of timezone database assumptions used by the producer.

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 records the timezone database release identifier used by the producer.

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 states how a many-candidate zoned civil mapping should be handled.

Allowed values:

gapPolicy states what a materializer may do after mapping returns zero candidates:

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 the WTC zone-resolution appendix.

Example:

event@{
  target = "zone"
  zone = "Australia/Melbourne"
  disambiguation = "reject"
}:datetime = 2025-04-06T02:30:00

A gap policy is separate:

skipped@{
  target = "zone"
  zone = "Australia/Melbourne"
  gapPolicy = "preserveClaim"
}:datetime = 2025-10-05T02:30:00

4.7 offset

offset records an offset associated with the value.

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 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:

Example metadata on an ordinary datetime:

observation@{
  timescale = "TT"
}:datetime = 2026-01-01T09:10:10

The same identifiers may be carried intrinsically as WTC temporal contexts:

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 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:

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:

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 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

Trusted resolver configuration and recorded resolution provenance use a common authority-reference shape:

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 lists target projection zones for display or transformation workflows.

apply = [
  "Australia/Perth"
  "Europe/Paris"
]

This field does not define execution semantics.

5. 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:

date:calendarDate = {
  calendar:string = "hebrew"
  year:int = 5779
  monthCode:string = "M05L"
  day:int = 23
}

A common calendar-native datetime adds a civil time:

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:

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

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:

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

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<datetime> = !"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

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

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:

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

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.