# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-22T21:28:49Z", "synthesisSha256": "797053dd17b2b74402d8a89d9ed08d28556c809ff48526d6b3ab075d4bf44ab3", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-XCT-009", "registryId": "vr.wm-xct-009", "name": "Time / Calendar", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "identifier systems", "namespaces", "reference data" ], "tags": [ "identifier", "namespace", "registry", "resolution", "interoperability" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-xct-009-time-calendar/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-009", "model": { "registry_id": "vr.wm-xct-009", "model_id": "WM-XCT-009", "name": "Time / Calendar", "entry_kind": "mixin", "purpose": "Provide a format-neutral, authority-grounded reference model for temporal reference data (time scales, civil time zones, calendar systems, recurrence, holidays and observances) together with the embeddable temporal value shapes that every other model needs to express instants, intervals, durations, schedules and deadlines unambiguously.", "scope_statement": "WM-XCT-009 is a mix-in plus reference model. It defines (a) the governed reference data that determines what a civil date-time means — time scales and leap adjustments, time zone identifiers and their offset-transition history, calendar systems, eras and week rules, and jurisdictional holidays and observances; and (b) the reusable temporal value shapes (instant, interval, duration, recurrence, precision, binding mode) that sibling models embed. It is storage- and interface-neutral: TZif, iCalendar, JSCalendar, JSON, XML, Git or MongoDB are projections of the same semantics. It records external standards as alignments, never as claimed conformance, and treats the IANA tz database and CLDR as mirrors of civil decisions rather than as the legal authority for them.", "in_scope": [ "Time scales, epochs and their mutual offsets (UTC, TAI, UT1, GPS time, POSIX/Unix time), and the governance of leap adjustments", "Civil time zone identity, canonical/alias relationships, standard and daylight offsets, and the complete transition history of a zone", "Legal instruments and decision processes by which a jurisdiction sets or changes standard time and daylight saving arrangements", "Calendar systems and their identifiers, eras and year numbering, intercalation and leap-month structure, and territory week rules", "Reusable temporal value shapes: instant, interval, duration, period, granularity/precision, and the floating/zoned/absolute binding contract", "Recurrence rule semantics, exceptions and overrides, and calendar-scale-aware recurrence expansion", "Public holidays as proclaimed by an authority, cultural and religious observances and their computation methods", "Working-day and business-day calendars, weekend rules and date-adjustment (business day) conventions", "Reference-data lifecycle: release versioning, signing, distribution, expiry, freshness and correction of temporal reference data" ], "out_of_scope": [ "Clock synchronisation and time transfer protocols and their engineering (NTP, PTP, GNSS timing, UTC(k) traceability chains) — a distinct time-dissemination model", "Calendaring and scheduling application semantics such as attendees, invitations, free/busy, alarms and iTIP scheduling workflows", "The definition and geometry of jurisdictions and territories themselves — held by the place/jurisdiction model and only referenced here", "General identifier-scheme governance — held by the identifier and naming model; this model only consumes registered temporal identifier schemes", "Astronomical ephemeris computation and the physics of Earth rotation; only the published results (leap-second decisions, DUT1 limits) are consumed", "Labour-law entitlements, pay premiums and leave accrual arising from holidays; only the day-off status of a holiday is modelled", "Domain deadline policy (SLA targets, statutory limitation periods); this model supplies the calculus, not the policy", "Localisation and formatting of dates for presentation, beyond the identifiers and week/calendar preference data needed to compute correct values" ], "boundary_notes": [ { "neighbor": "Place / jurisdiction reference model", "distinction": "Time zones and holidays are scoped to jurisdictions and sub-jurisdictional divisions (for example the UK bank-holiday divisions england-and-wales, scotland, northern-ireland, or US county-level zone boundaries in 49 CFR Part 71). This model references those jurisdiction identities; it does not define territories, boundaries or their geometry. tz zone names are deliberately not country-based and must not be treated as jurisdiction identifiers.", "source_refs": [ "SRC-003", "SRC-019", "SRC-020" ] }, { "neighbor": "Identifier and naming model", "distinction": "tzids, CLDR BCP47 timezone keys and u-ca calendar keys are governed identifier schemes maintained elsewhere. This model records which scheme an identifier belongs to, its canonical form and its alias relations; scheme registration policy itself belongs to the identifier model.", "source_refs": [ "SRC-011", "SRC-013", "SRC-002" ] }, { "neighbor": "Time dissemination and clock synchronisation model", "distinction": "BIPM Circular T and IERS bulletins are consumed here as authoritative statements about the scale (leap seconds, UTC-TAI, UTC(k) deviations). How a device acquires and steers to that scale, and traceability of a local clock, is a separate engineering model.", "source_refs": [ "SRC-014", "SRC-015", "SRC-023" ] }, { "neighbor": "Calendaring and scheduling application model", "distinction": "RFC 5545 and RFC 8984 are alignments for recurrence and time-zone value semantics only. Event participation, scheduling negotiation and calendar-store synchronisation belong to an application model that embeds this mix-in.", "source_refs": [ "SRC-007", "SRC-009" ] }, { "neighbor": "Financial settlement and instrument models", "distinction": "Business day conventions and business-centre holiday calendars are defined here as reusable date arithmetic. Which convention a given contract or instrument elects is a fact of that instrument, held by the financial model.", "source_refs": [ "SRC-021" ] }, { "neighbor": "Statistics and records models", "distinction": "Reference periods, retention triggers and reporting cut-offs embed this model's interval and recurrence shapes. The meaning of a reference period for a statistic, or of a retention trigger for a record, stays with those models.", "source_refs": [ "SRC-017", "SRC-007" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Time Zone Database (tz database), release 2026c", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/time-zones", "version_or_date": "Release 2026c, issued 2026-07-08", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "The de facto global registry of civil time zone identifiers, offsets and transition history; the release identifier is the versioning anchor for all zone-dependent computation." }, { "id": "SRC-002", "title": "RFC 6557 — Procedures for Maintaining the Time Zone Database (BCP 175)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc6557.html", "version_or_date": "February 2012, Best Current Practice", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative governance of the tz database: the TZ Coordinator role, proposal and decision process, release signing, and the explicit statement that the database records rather than sets civil time policy." }, { "id": "SRC-003", "title": "Theory and pragmatics of the tz code and data", "organization": "IANA / tz project", "url": "https://data.iana.org/time-zones/theory.html", "version_or_date": "Accompanying tzdb release 2026c", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "First-party specification of Zone/Rule/Link semantics, naming and stability guarantees, zone1970.tab and zonenow.tab, and the explicit accuracy caveats for pre-1970 and future timestamps." }, { "id": "SRC-004", "title": "RFC 9636 — The Time Zone Information Format (TZif)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc9636.html", "version_or_date": "October 2024, Standards Track; obsoletes RFC 8536", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative binary projection of zone data: transition times, local time type records (utoff, isdst, desigidx), leap-second records, POSIX TZ footer and version 4 leap-table expiration." }, { "id": "SRC-005", "title": "RFC 3339 — Date and Time on the Internet: Timestamps", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "July 2002, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "The mandated timestamp profile for this model: full-date/full-time grammar, explicit offset or Z, the -00:00 unknown-offset convention, and 23:59:60 leap-second representation." }, { "id": "SRC-006", "title": "RFC 9557 — Date and Time on the Internet: Timestamps with Additional Information (IXDTF)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc9557.html", "version_or_date": "April 2024, Proposed Standard; updates RFC 3339", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Defines carrying time zone and calendar annotations alongside an instant, the critical-flag processing requirement, and the reinterpretation of Z as 'offset to local time unknown'." }, { "id": "SRC-007", "title": "RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc5545.html", "version_or_date": "September 2009, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative semantics for VTIMEZONE observances, the RECUR value type, EXDATE/RDATE, DURATION and PERIOD, and the floating / UTC / TZID-bound date-time distinction." }, { "id": "SRC-008", "title": "RFC 7529 — Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc7529.html", "version_or_date": "May 2015, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Binds recurrence expansion to a named calendar system via RSCALE using the Unicode calendar registry, and defines SKIP=OMIT/BACKWARD/FORWARD and leap-month 'L' notation." }, { "id": "SRC-009", "title": "RFC 8984 — JSCalendar: A JSON Representation of Calendar Data", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc8984.html", "version_or_date": "July 2021, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "An independent, non-iCalendar projection of the same temporal semantics: LocalDateTime vs UTCDateTime, timeZone, embedded timeZones, recurrenceRules and recurrenceOverrides, showWithoutTime." }, { "id": "SRC-010", "title": "RFC 7808 — Time Zone Data Distribution Service (TZDIST)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc7808.html", "version_or_date": "March 2016, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative model for versioning and distributing zone data: monolithic vs incremental versions, truncation with TZUNTIL, alias/canonical handling, expand and leapseconds actions, ETag and sync-token change detection." }, { "id": "SRC-011", "title": "Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML), Part 4: Dates", "organization": "Unicode Consortium", "url": "https://www.unicode.org/reports/tr35/tr35-dates.html", "version_or_date": "CLDR / LDML version 48.2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative calendar and era data structures (era code, start/end in proleptic Gregorian, inheritEras) and the stable CLDR timezone identifier layer with metazones and alias equivalences over the volatile tzdb." }, { "id": "SRC-012", "title": "Unicode Technical Standard #35: LDML, Part 6: Supplemental", "organization": "Unicode Consortium", "url": "https://www.unicode.org/reports/tr35/tr35-info.html", "version_or_date": "CLDR / LDML version 48.2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Supplemental territory-scoped data: week data (first day of week, weekend days, minimum days), calendar preference by region, timezoneData, metazoneInfo, primaryZones and windowsZones." }, { "id": "SRC-013", "title": "CLDR BCP 47 calendar key registry (common/bcp47/calendar.xml)", "organization": "Unicode Consortium", "url": "https://github.com/unicode-org/cldr/blob/main/common/bcp47/calendar.xml", "version_or_date": "CLDR main branch, accessed 2026-08-22", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "The governed registry of calendar identifiers (u-ca values) referenced normatively by RFC 7529 and RFC 9557, including Hijri variants that differ by determination method and the deprecated islamicc alias." }, { "id": "SRC-014", "title": "Resolution 4 of the 27th CGPM (2022): On the use and future development of UTC", "organization": "Bureau International des Poids et Mesures (BIPM) / CGPM", "url": "https://www.bipm.org/en/cgpm-2022/resolution-4", "version_or_date": "27th CGPM, November 2022", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "The decision that the maximum value of UT1-UTC will be increased in or before 2035, with CIPM to propose the new maximum and implementation plan; the governing lifecycle event for leap-second policy." }, { "id": "SRC-015", "title": "IERS Bulletin C 72", "organization": "International Earth Rotation and Reference Systems Service (IERS), Earth Orientation Centre", "url": "https://datacenter.iers.org/data/latestVersion/bulletinC.txt", "version_or_date": "Bulletin C 72, issued 2026-07-06", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "The authoritative serial announcement of leap-second insertion or non-insertion; confirms no leap second at end of December 2026 and UTC-TAI = -37 s since 2017-01-01." }, { "id": "SRC-016", "title": "leap-seconds.list", "organization": "IANA / IERS", "url": "https://data.iana.org/time-zones/data/leap-seconds.list", "version_or_date": "Distributed with tzdb; expires 2027-06-28", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Machine-readable leap-second table with NTP-epoch timestamps, cumulative TAI-UTC values, an explicit last-update line and an expiration line — the canonical model for temporal reference data that expires." }, { "id": "SRC-017", "title": "Time Ontology in OWL", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl-time/", "version_or_date": "W3C Candidate Recommendation Draft, 2022-11-15; namespace http://www.w3.org/2006/time#", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Format-neutral conceptual vocabulary for temporal entities: Instant, ProperInterval, Duration, GeneralDateTimeDescription, TemporalPosition with hasTRS, and the thirteen/fifteen Allen interval relations." }, { "id": "SRC-018", "title": "Directive 2000/84/EC of the European Parliament and of the Council of 19 January 2001 on summer-time arrangements", "organization": "European Union (EUR-Lex, CELEX 32000L0084)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32000L0084", "version_or_date": "OJ L 31, 2001-02-02, p. 21-22; in force", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "A concrete legal instrument that defines a daylight-saving rule (last Sunday in March to last Sunday in October, 01:00 GMT) and requires the Commission to publish a five-year timetable — the authority layer beneath tzdb entries." }, { "id": "SRC-019", "title": "UK bank holidays (machine-readable calendar)", "organization": "Government Digital Service, GOV.UK", "url": "https://www.gov.uk/bank-holidays.json", "version_or_date": "Live feed covering 2019-01-01 to 2028-12-26; accessed 2026-08-22", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "A first-party public-authority holiday feed showing the minimum viable holiday record: division scoping, title, date, substitute-day notes, and a rolling publication horizon." }, { "id": "SRC-020", "title": "49 CFR Part 71 — Standard Time Zone Boundaries", "organization": "U.S. Department of Transportation / Office of the Federal Register (govinfo)", "url": "https://www.govinfo.gov/content/pkg/CFR-2024-title49-vol1/pdf/CFR-2024-title49-vol1-part71.pdf", "version_or_date": "CFR annual edition, title 49 volume 1 (2024/2025 print)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Demonstrates that civil zone boundaries are legally defined by an administering authority under the Uniform Time Act with a petition-and-rulemaking change process, described by county and municipal lines rather than by tz identifiers." }, { "id": "SRC-021", "title": "FpML BusinessDayConventionEnum (fpml-enum-5-5)", "organization": "ISDA / FpML", "url": "https://www.fpml.org/spec/fpml-5-5-4-tr-1/html/reporting/schemaDocumentation/schemas/fpml-enum-5-5_xsd/simpleTypes/BusinessDayConventionEnum.html", "version_or_date": "FpML 5.5 Recommendation schema documentation", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Normative enumeration and definitions of date-adjustment conventions (FOLLOWING, MODFOLLOWING, PRECEDING, MODPRECEDING, NEAREST, FRN, NONE, NotApplicable) used by working-day calendars." }, { "id": "SRC-022", "title": "CLDR Releases / Downloads", "organization": "Unicode Consortium", "url": "https://cldr.unicode.org/index/downloads", "version_or_date": "CLDR 48.2, released 2026-03-17", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Authoritative release identity and date for the CLDR data version that must be pinned alongside a tzdb release when reproducing a temporal computation." }, { "id": "SRC-023", "title": "BIPM Circular T archive (latest issue cirt.463)", "organization": "Bureau International des Poids et Mesures (BIPM), Time Department", "url": "https://webtai.bipm.org/ftp/pub/tai/Circular-T/cirt/", "version_or_date": "Circular T 463, dated 2026-08-11", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "Monthly authoritative publication relating UTC to its local realisations UTC(k); evidence that UTC is a computed, published scale with a serial, dated artifact rather than a static constant." }, { "id": "SRC-024", "title": "Date and Time Formats (W3C Note, profile of ISO 8601)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/NOTE-datetime.html", "version_or_date": "W3C Note, 1997-09-15", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:00:00Z", "relevance": "An accessible, citable statement of the ISO 8601 granularity ladder (year, year-month, date, date+hh:mm, +ss, +fraction) and the requirement that an adopting standard declare which granularities and offset forms it supports." }, { "id": "SRC-025", "title": "Theory and pragmatics of the tz code and data", "organization": "Internet Assigned Numbers Authority", "url": "https://www.iana.org/time-zones/theory", "version_or_date": "tzdb community theory (current with 2026c)", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Defines timezone naming policy, link and backward compatibility, zone table scope, and the limits of pre-1970 historical data." }, { "id": "SRC-026", "title": "Leap second and UT1-UTC information", "organization": "National Institute of Standards and Technology", "url": "https://www.nist.gov/pml/time-and-frequency-division/time-realization/leap-seconds", "version_or_date": "2026-02-25", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Inserted leap-second dates with MJD, the current TAI-UTC value of 37 seconds, and UT1-UTC and DUT1 series." }, { "id": "SRC-027", "title": "THE LEAP SECOND", "organization": "IERS Earth Orientation Center, Paris Observatory", "url": "https://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html", "version_or_date": "current IERS Earth Orientation Center page; last leap second 2017-01-01T00:00:00Z", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Authority and Bulletin C process for announcing leap seconds, and the requirement to keep UTC within 0.9 second of UT1." }, { "id": "SRC-028", "title": "Unicode Locale Data Markup Language (LDML) Part 4: Dates", "organization": "Unicode Consortium", "url": "https://unicode-org.github.io/cldr/ldml/tr35-dates.html", "version_or_date": "UTS #35 living LDML (CLDR calendar types current on access date)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "BCP 47 calendar type inventory, era, month and week data, and locale display names for calendars and timezones." }, { "id": "SRC-029", "title": "RFC 7529: Non-Gregorian Recurrence Rules in iCalendar", "organization": "Internet Engineering Task Force", "url": "https://datatracker.ietf.org/doc/rfc7529/", "version_or_date": "2015-05", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "RSCALE extension enabling recurrence evaluated on non-Gregorian calendars, and the record that CALSCALE was never used in practice." }, { "id": "SRC-030", "title": "C132 - Holidays with Pay Convention (Revised), 1970 (No. 132)", "organization": "International Labour Organization", "url": "https://www.ilo.org/resource/c132-holidays-pay-convention-revised-1970", "version_or_date": "1970-06-24", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Distinguishes public and customary holidays from annual paid leave; the only retrieved primary instrument bearing on holiday semantics." }, { "id": "SRC-031", "title": "How to Read the tz Database Source Files", "organization": "Internet Assigned Numbers Authority", "url": "https://data.iana.org/time-zones/tz-how-to.html", "version_or_date": "current with tzdb distribution", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Field-level semantics of Zone and Rule lines: STDOFF, RULES, FORMAT, UNTIL, SAVE, LETTER and the AT clock suffixes." } ], "structure": { "bundles": [ { "id": "time-base", "name": "Time base", "description": "The physical and computational substrate for locating an instant: named time scales, their epochs and mutual offsets, the governance of leap adjustments, and the rules for representing an instant with declared precision.", "rationale": "Every downstream temporal statement resolves, directly or indirectly, to an instant on a named scale. Scale choice and leap handling are authority-managed and change by international decision, so they must be modelled before zones, calendars or schedules.", "source_refs": [ "SRC-005", "SRC-014", "SRC-015", "SRC-016", "SRC-023" ], "layers": [ { "id": "time-scale-and-epoch", "name": "Time scale and epoch", "description": "Named reference scales (UTC, TAI, UT1, GPS time, POSIX/Unix time, terrestrial time), their epochs, their continuity properties and the offsets that relate them.", "source_refs": [ "SRC-014", "SRC-016", "SRC-023", "SRC-017" ], "findings": [ { "id": "time-scale-definition", "name": "Time scale definition and inter-scale offset", "description": "A time scale is a governed system for locating instants, characterised by its defining authority, epoch, unit, and whether it is continuous (TAI, GPS) or subject to discontinuities (UTC). Statements are only comparable when the scale is declared; the current relation UTC = TAI - 37 s has been in force since 2017-01-01 and is itself a dated fact.", "source_refs": [ "SRC-014", "SRC-015", "SRC-016", "SRC-023", "SRC-017" ], "questions": [ { "id": "tsd-q1", "text": "Which named time scale does this temporal value use, and is that scale explicitly declared or merely assumed?", "kind": "definition", "answer_data": [ "scale identifier", "scale declaration mode (explicit, inherited, assumed)", "default scale for the containing model" ] }, { "id": "tsd-q2", "text": "Which body defines and publishes this scale, and through which serial publication is its realisation disseminated?", "kind": "authority", "answer_data": [ "defining authority", "publishing authority", "publication series identifier", "latest issue identifier and date" ] }, { "id": "tsd-q3", "text": "Is the scale continuous, or may it contain inserted or removed seconds that break naive arithmetic?", "kind": "classification", "answer_data": [ "continuity class (continuous, stepped, smeared, undefined)", "discontinuity mechanism", "known discontinuity count" ] }, { "id": "tsd-q4", "text": "What is the offset from this scale to UTC at a given instant, and from when is that offset valid?", "kind": "measurement", "answer_data": [ "offset value with unit", "valid-from instant", "valid-until instant or open", "source publication reference" ] }, { "id": "tsd-q5", "text": "Which scale is used for the underlying storage representation, and does it differ from the scale used for display or comparison?", "kind": "interoperability", "answer_data": [ "storage scale identifier", "comparison scale identifier", "conversion rule reference" ] } ], "data_elements": [ { "id": "scale-id", "name": "scaleId", "description": "Stable identifier of the time scale (for example UTC, TAI, UT1, GPS, UNIX).", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "scale-epoch", "name": "epochInstant", "description": "The instant from which the scale's count or numbering begins, expressed on a declared reference scale.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-005" ] }, { "id": "scale-continuity", "name": "continuityClass", "description": "Whether the scale is continuous, stepped by leap adjustments, smeared, or unspecified.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-016" ] }, { "id": "scale-offset-to-utc", "name": "offsetToUtc", "description": "Signed offset from this scale to UTC, valid over a stated period.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "scale-authority-ref", "name": "definingAuthorityRef", "description": "Reference to the organisation that defines the scale and to the serial publication that realises it.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-014", "SRC-023" ] } ], "artifacts": [ { "id": "time-scale-register", "name": "Time scale register", "description": "The curated set of time scales recognised by the adopting Dimension, with epochs, continuity classes and inter-scale offset histories.", "media_or_form": [ "structured record set", "tabular reference data", "ontology individuals" ], "serial": false, "identity_strategy": "Governed scale identifiers (UTC, TAI, GPS, UT1) as authoritative master-system identifiers; the register itself carries a Dimension-assigned UUID and a release identifier.", "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "scale-realisation-bulletin", "name": "Scale realisation bulletin", "description": "A dated, numbered publication relating the scale to its local realisations, such as BIPM Circular T.", "media_or_form": [ "numbered bulletin document", "fixed-width data table" ], "serial": true, "identity_strategy": "Publisher's serial number plus issue date (for example Circular T 463 of 2026-08-11); never identified by date alone.", "source_refs": [ "SRC-023" ] } ], "inline_only_rationale": null } ] }, { "id": "leap-adjustment-governance", "name": "Leap adjustment and UTC governance", "description": "How leap seconds are decided, announced, tabulated, represented and retired, including the CGPM decision to raise the UT1-UTC tolerance by 2035.", "source_refs": [ "SRC-014", "SRC-015", "SRC-016", "SRC-005", "SRC-004" ], "findings": [ { "id": "leap-second-adjustment", "name": "Leap adjustment decision, table and expiry", "description": "Leap seconds are announced by IERS in serial Bulletin C notices, tabulated in a machine-readable list carrying an explicit expiration, represented in timestamps as second value 60, and are subject to a standing CGPM decision to increase the permitted UT1-UTC difference in or before 2035. A leap table is therefore a perishable artifact, not a constant.", "source_refs": [ "SRC-014", "SRC-015", "SRC-016", "SRC-005", "SRC-004" ], "questions": [ { "id": "lsa-q1", "text": "Which body decides a leap adjustment, and by which dated instrument was the most recent decision announced?", "kind": "authority", "answer_data": [ "deciding body", "bulletin series and number", "issue date", "decision outcome (insert, remove, none)" ] }, { "id": "lsa-q2", "text": "What is the cumulative TAI-UTC value at a given instant, and when does the consulted leap table expire?", "kind": "temporal", "answer_data": [ "cumulative offset in seconds", "effective-from instant", "table last-update instant", "table expiration instant" ] }, { "id": "lsa-q3", "text": "How does this system represent or avoid the 60th second, and is that behaviour declared?", "kind": "constraint", "answer_data": [ "leap representation policy (represent as :60, smear, reject, clamp)", "smear window and shape if applicable", "affected interfaces" ] }, { "id": "lsa-q4", "text": "What happens to stored durations and orderings computed before a leap adjustment took effect?", "kind": "lifecycle", "answer_data": [ "recomputation policy", "affected record classes", "recomputation event log reference" ] }, { "id": "lsa-q5", "text": "How will the planned change to the UT1-UTC tolerance by 2035 affect assumptions currently baked into this Dimension?", "kind": "decision", "answer_data": [ "dependency inventory on leap-second insertion", "planned migration action", "owner", "target date" ] }, { "id": "lsa-q6", "text": "Is the leap table currently in use still valid, and what is done when it has expired?", "kind": "validation", "answer_data": [ "freshness check result", "expiry instant", "stale-data fallback behaviour", "alerting target" ] } ], "data_elements": [ { "id": "leap-event-instant", "name": "leapEventInstant", "description": "The instant at which a leap adjustment takes or took effect, on the UTC scale.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-015" ] }, { "id": "leap-cumulative-offset", "name": "cumulativeTaiUtcOffset", "description": "Cumulative TAI-UTC difference in whole seconds after the adjustment.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "leap-table-expiry", "name": "leapTableExpiresAt", "description": "The instant after which the leap-second table must not be relied upon.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-004" ] }, { "id": "leap-announcement-ref", "name": "announcementRef", "description": "Reference to the serial bulletin that announced the decision.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "leap-handling-policy", "name": "leapHandlingPolicy", "description": "Declared behaviour of this system when a leap second occurs or is encountered in input.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-004" ] } ], "artifacts": [ { "id": "leap-second-table", "name": "Leap second table", "description": "Machine-readable table of leap events with cumulative offsets, a last-update marker and an explicit expiration marker.", "media_or_form": [ "delimited text table", "binary leap records inside a zone information file" ], "serial": true, "identity_strategy": "Publisher URL plus the table's own last-update timestamp; supersession is by later last-update value, and the expiration value governs usability.", "source_refs": [ "SRC-016", "SRC-004" ] }, { "id": "leap-decision-notice", "name": "Leap decision notice", "description": "The numbered bulletin announcing insertion or non-insertion of a leap second at the next opportunity.", "media_or_form": [ "plain-text bulletin", "authority web notice" ], "serial": true, "identity_strategy": "Issuing authority plus bulletin series and sequence number (for example IERS Bulletin C 72), with issue date recorded separately from effective date.", "source_refs": [ "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "instant-precision-and-resolution", "name": "Instant representation and precision", "description": "How a single point in time is written down: the mandated timestamp profile, offset semantics, fractional precision, and the separation of event time from observation time.", "source_refs": [ "SRC-005", "SRC-006", "SRC-024", "SRC-017" ], "findings": [ { "id": "instant-representation", "name": "Instant representation profile", "description": "An instant is recorded using an RFC 3339 date-time with an explicit numeric offset or Z, optionally annotated per RFC 9557 with the originating time zone and calendar. The distinct meanings of Z, +00:00 and -00:00, the declared fractional precision, and the separation of event time from observation or ingestion time are all part of the record's meaning.", "source_refs": [ "SRC-005", "SRC-006", "SRC-024", "SRC-017" ], "questions": [ { "id": "ir-q1", "text": "Does every recorded instant carry an explicit offset or Z, and are unqualified local times rejected at the boundary?", "kind": "validation", "answer_data": [ "offset presence rule", "validation error code for missing offset", "count of legacy values lacking offset" ] }, { "id": "ir-q2", "text": "Is the offset a known local offset, an assertion of UTC preference, or a declaration that the local offset is unknown?", "kind": "definition", "answer_data": [ "offset form used (Z, +00:00, -00:00, numeric)", "interpretation note", "originating locality if known" ] }, { "id": "ir-q3", "text": "What fractional-second precision is stored, and is stored precision distinguished from measured precision?", "kind": "measurement", "answer_data": [ "stored decimal places", "measurement resolution", "truncation or rounding rule" ] }, { "id": "ir-q4", "text": "Are event time and observation or ingestion time recorded separately for this record class?", "kind": "provenance", "answer_data": [ "event time field", "observation time field", "ingestion time field", "clock source for each" ] }, { "id": "ir-q5", "text": "When an instant is annotated with a time zone, is that annotation critical, and what must happen if it contradicts the offset?", "kind": "exception", "answer_data": [ "annotation criticality flag", "conflict detection rule", "action on conflict (reject, prefer offset, prefer zone)" ] } ], "data_elements": [ { "id": "instant-value", "name": "instantValue", "description": "The point in time, expressed with date, time and explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "instant-zone-annotation", "name": "zoneAnnotation", "description": "Optional originating time zone identifier carried with the instant, with a criticality flag.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "instant-calendar-annotation", "name": "calendarAnnotation", "description": "Optional preferred calendar for presenting the instant, expressed as a registered calendar key.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-013" ] }, { "id": "instant-precision", "name": "declaredPrecision", "description": "The granularity actually asserted by the value, independent of the digits stored.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024", "SRC-017" ] }, { "id": "observation-instant", "name": "observedAt", "description": "When the value was observed, recorded or ingested, as distinct from when the described event occurred.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "timestamp-conformance-profile", "name": "Timestamp conformance profile", "description": "A declared profile stating which granularities, offset forms, annotations and precision this Dimension accepts and emits, as required when adopting an ISO 8601 profile.", "media_or_form": [ "profile specification document", "machine-readable validation ruleset" ], "serial": false, "identity_strategy": "Dimension-assigned identifier plus semantic version; superseded profiles retained with effective-from and effective-until instants.", "source_refs": [ "SRC-024", "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "civil-time-zone", "name": "Civil time zone", "description": "The identity, offset history, resolution behaviour and legal basis of civil time zones — the machinery that converts between wall-clock time in a place and an instant.", "rationale": "Zone data is the single largest source of temporal defects: identifiers are aliased and unstable, rules change by decree with little notice, and local times can be ambiguous or non-existent. Each of these is a separately answerable body of context.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-011", "SRC-018", "SRC-020" ], "layers": [ { "id": "zone-identity-and-registry", "name": "Zone identity and registry", "description": "How a time zone is named and identified, the canonical versus alias distinction, the stable CLDR identifier layer, and what must never be used as an identifier.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-010", "SRC-002" ], "findings": [ { "id": "zone-identifier", "name": "Zone identifier, canonicality and aliases", "description": "A civil zone is identified by a tz identifier in Area/Location form, which may be a primary zone or a backward-compatibility link to another zone. CLDR maintains a deliberately more stable identifier layer with documented alias equivalences, because zone names, boundaries, offsets and abbreviations are explicitly not all stable interfaces.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-010", "SRC-002" ], "questions": [ { "id": "zi-q1", "text": "Which identifier scheme is this zone identifier drawn from, and is the value canonical or an alias?", "kind": "identity", "answer_data": [ "identifier scheme", "identifier value", "canonical form", "alias-of target" ] }, { "id": "zi-q2", "text": "Which stable identifier does this Dimension persist when the upstream registry renames or relinks a zone?", "kind": "interoperability", "answer_data": [ "persisted identifier layer (tz canonical, CLDR BCP47 key, internal surrogate)", "mapping table reference", "rename handling rule" ] }, { "id": "zi-q3", "text": "Are zone abbreviations, numeric offsets or country codes ever used to identify a zone in this system?", "kind": "constraint", "answer_data": [ "prohibited identifier forms in use", "remediation plan", "affected interfaces" ] }, { "id": "zi-q4", "text": "What happens to stored references when a zone is split, merged or retired upstream?", "kind": "lifecycle", "answer_data": [ "split or merge event record", "superseding identifier", "migration rule for stored references", "effective instant" ] }, { "id": "zi-q5", "text": "Which geographic region does this identifier actually cover, and is that coverage authoritative for jurisdictional purposes?", "kind": "spatial", "answer_data": [ "region description from the zone table", "representative coordinates", "jurisdiction reference", "authoritativeness caveat" ] } ], "data_elements": [ { "id": "tz-id", "name": "tzId", "description": "Time zone identifier in Area/Location form as published by the tz database.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "tz-canonical-flag", "name": "isCanonical", "description": "Whether the identifier is a primary zone rather than a backward link.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-010" ] }, { "id": "tz-alias-of", "name": "aliasOf", "description": "The canonical zone identifier that this alias resolves to.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "tz-stable-key", "name": "stableZoneKey", "description": "The stability-preserving identifier layer used for persistence, such as the CLDR BCP47 timezone key.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tz-region-ref", "name": "coveredRegionRef", "description": "Reference to the jurisdiction or region the zone represents, drawn from the place model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "tz-metazone", "name": "metazoneRef", "description": "Grouping used for shared display names across a period, where a presentation layer needs it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] } ], "artifacts": [ { "id": "zone-identifier-crosswalk", "name": "Zone identifier crosswalk", "description": "Mapping between tz canonical identifiers, backward links, CLDR stable keys, legacy platform identifiers and any internal surrogates.", "media_or_form": [ "mapping table", "reference dataset" ], "serial": false, "identity_strategy": "Keyed on the tz canonical identifier as the authoritative master-system identifier; the crosswalk carries a Dimension UUID plus the tzdb and CLDR release identifiers it was built against.", "source_refs": [ "SRC-001", "SRC-011", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "offset-rule-and-transition-history", "name": "Offset rule and transition history", "description": "The rule and transition structures that give a zone its offset at any instant, including daylight indicators, designations, projections and truncation.", "source_refs": [ "SRC-003", "SRC-004", "SRC-007", "SRC-010", "SRC-001" ], "findings": [ { "id": "offset-transition-record", "name": "Offset transition and local time type", "description": "A zone's behaviour is a sorted series of transitions, each selecting a local time type consisting of a UTC offset, a daylight indicator and a designation. Rules need not alternate between two states, may change more than twice per year, and future behaviour beyond the last explicit transition is governed by a projected rule string or by a stated validity limit.", "source_refs": [ "SRC-003", "SRC-004", "SRC-007", "SRC-010" ], "questions": [ { "id": "otr-q1", "text": "What is the complete ordered series of offset transitions for this zone over the period the data must serve?", "kind": "composition", "answer_data": [ "transition instants on the reference scale", "offset before", "offset after", "daylight indicator", "designation" ] }, { "id": "otr-q2", "text": "Until what instant is the zone data explicitly valid, and how is behaviour beyond that point derived?", "kind": "temporal", "answer_data": [ "validity upper bound", "projection rule expression", "truncation start point", "projection reliability note" ] }, { "id": "otr-q3", "text": "Was a given transition a historical fact, a scheduled future change, or a prediction from a repeating rule?", "kind": "state", "answer_data": [ "transition status (historical, scheduled, predicted)", "announcing instrument reference", "confidence" ] }, { "id": "otr-q4", "text": "Which upstream release supplied this transition series, and has any transition changed between releases?", "kind": "provenance", "answer_data": [ "upstream release identifier", "previous value", "change instant", "change reason" ] }, { "id": "otr-q5", "text": "Is the recorded pre-1970 history evidence-backed or reconstructed, and is that distinction visible to consumers?", "kind": "evidence", "answer_data": [ "evidence class", "source citation", "known-inaccuracy flag", "consumer-facing warning" ] }, { "id": "otr-q6", "text": "Which projection formats must this transition series be emitted in, and are they lossless with respect to each other?", "kind": "interoperability", "answer_data": [ "target formats", "fields lost per format", "round-trip test result" ] } ], "data_elements": [ { "id": "transition-instant", "name": "transitionAt", "description": "The instant at which a new local time type takes effect.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "offset-before", "name": "offsetBefore", "description": "UTC offset in force immediately before the transition.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-004" ] }, { "id": "offset-after", "name": "offsetAfter", "description": "UTC offset in force immediately after the transition.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-004" ] }, { "id": "is-daylight", "name": "isDaylight", "description": "Whether the resulting local time type is a daylight saving observance.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "zone-designation", "name": "designation", "description": "Abbreviation displayed for the local time type; explicitly not usable as an identifier.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] }, { "id": "zone-valid-until", "name": "validUntil", "description": "Upper bound of asserted validity for truncated zone data.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "future-rule-expression", "name": "futureRuleExpression", "description": "Rule used to project transitions beyond the last explicit entry.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [ { "id": "zone-information-file", "name": "Zone information file", "description": "Binary projection of the transition series, local time types, designations, leap records and projection footer.", "media_or_form": [ "binary time zone information file", "versioned data block" ], "serial": false, "identity_strategy": "Zone canonical identifier plus the producing release identifier and format version; content hash recorded for integrity.", "source_refs": [ "SRC-004" ] }, { "id": "zone-observance-component", "name": "Zone observance component", "description": "Textual calendaring projection of a zone as standard and daylight observances with offsets, names and recurrence or explicit dates.", "media_or_form": [ "calendaring object component", "JSON time zone object" ], "serial": false, "identity_strategy": "Zone identifier plus validity upper bound; alias origin recorded when the component was requested under a non-canonical name.", "source_refs": [ "SRC-007", "SRC-009", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "local-time-anomaly-resolution", "name": "Local time anomaly resolution", "description": "Deterministic handling of wall-clock times that do not exist or occur twice, and of timestamps whose offset contradicts their declared zone.", "source_refs": [ "SRC-007", "SRC-009", "SRC-006", "SRC-003" ], "findings": [ { "id": "wall-clock-ambiguity-policy", "name": "Gap, overlap and offset-conflict policy", "description": "Around a transition, a local wall-clock time may be skipped or may occur twice, and a supplied offset may disagree with the supplied zone. A conforming system must declare a deterministic resolution policy; where a zone annotation is marked critical the inconsistency must be acted upon rather than silently ignored.", "source_refs": [ "SRC-006", "SRC-007", "SRC-009", "SRC-003" ], "questions": [ { "id": "wcap-q1", "text": "When a stated local time falls in a transition gap, is it rejected, shifted forward, or shifted by the gap duration?", "kind": "exception", "answer_data": [ "gap policy code", "shift amount rule", "error surface", "affected operations" ] }, { "id": "wcap-q2", "text": "When a stated local time is ambiguous, is the earlier or later occurrence chosen, and can the caller override?", "kind": "decision", "answer_data": [ "default disambiguation choice", "caller override parameter", "recorded chosen offset" ] }, { "id": "wcap-q3", "text": "If the supplied offset contradicts the supplied zone identifier, which wins, and is the annotation critical?", "kind": "constraint", "answer_data": [ "criticality flag", "precedence rule", "rejection condition", "diagnostic emitted" ] }, { "id": "wcap-q4", "text": "Is the resolved offset persisted alongside the local time so the resolution is reproducible later?", "kind": "validation", "answer_data": [ "persisted resolved offset", "resolution timestamp", "zone data release used" ] }, { "id": "wcap-q5", "text": "How are recurring local-time series handled when a future instance lands in a gap created by a later rule change?", "kind": "process", "answer_data": [ "re-expansion trigger", "instance adjustment rule", "notification to dependents" ] } ], "data_elements": [ { "id": "gap-policy", "name": "gapPolicy", "description": "Declared behaviour for non-existent local times.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "overlap-policy", "name": "overlapPolicy", "description": "Declared behaviour for ambiguous local times.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "resolved-offset", "name": "resolvedOffset", "description": "The offset actually selected when a local time was resolved to an instant.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "conflict-action", "name": "offsetZoneConflictAction", "description": "Action taken when a supplied offset and zone disagree.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "disambiguation-policy-statement", "name": "Disambiguation policy statement", "description": "Published statement of gap, overlap and conflict handling, so that consumers can reproduce a resolution.", "media_or_form": [ "policy document", "machine-readable configuration" ], "serial": false, "identity_strategy": "Dimension-assigned identifier with semantic version and effective-from instant; changes are breaking and require a new version.", "source_refs": [ "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "zone-legal-authority", "name": "Zone legal authority and change process", "description": "The legal instruments and administrative processes by which jurisdictions set standard time and daylight saving arrangements, and the distinction between those instruments and their database mirror.", "source_refs": [ "SRC-018", "SRC-020", "SRC-002", "SRC-003" ], "findings": [ { "id": "civil-time-decree", "name": "Civil time decree and its mirroring", "description": "Standard time and daylight saving arrangements are set by legal instruments — directives, statutes, regulations and proclamations — with a defined administering authority and change procedure. The tz database mirrors the resulting consensus on the ground and its coordinator explicitly does not set policy, so the legal instrument, not the database entry, is the authority of record.", "source_refs": [ "SRC-018", "SRC-020", "SRC-002", "SRC-003" ], "questions": [ { "id": "ctd-q1", "text": "Which authority is legally competent to change standard time or daylight arrangements for this territory?", "kind": "authority", "answer_data": [ "competent authority", "statutory basis citation", "scope of competence" ] }, { "id": "ctd-q2", "text": "By which dated instrument was the current arrangement established, and where was it officially published?", "kind": "provenance", "answer_data": [ "instrument title", "instrument identifier", "official publication reference", "publication date" ] }, { "id": "ctd-q3", "text": "What is the procedure and evidentiary threshold for changing a boundary or an exemption?", "kind": "process", "answer_data": [ "petition or proposal route", "evidence requirement", "consultation step", "decision instrument" ] }, { "id": "ctd-q4", "text": "When does the change take legal effect, and how much notice was given before that instant?", "kind": "temporal", "answer_data": [ "effective instant", "announcement instant", "notice period", "retroactivity flag" ] }, { "id": "ctd-q5", "text": "Who owns the record of this arrangement in the adopting Dimension, and who mirrors it into machine data?", "kind": "ownership", "answer_data": [ "record owner", "mirroring steward", "upstream mirror release in which it appeared" ] }, { "id": "ctd-q6", "text": "Is the machine data currently consistent with the legal instrument, and what is done while they diverge?", "kind": "quality", "answer_data": [ "divergence flag", "divergence description", "interim override rule", "review date" ] } ], "data_elements": [ { "id": "decree-instrument-id", "name": "instrumentIdentifier", "description": "Authoritative identifier of the legal instrument, such as a CELEX number, statute citation or regulation part.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-018", "SRC-020" ] }, { "id": "decree-authority", "name": "competentAuthority", "description": "The body empowered to make or amend the arrangement.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-020", "SRC-018" ] }, { "id": "decree-effective-at", "name": "effectiveAt", "description": "Instant at which the arrangement takes legal effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "decree-announced-at", "name": "announcedAt", "description": "Instant at which the change was publicly announced, recorded separately from the effective instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-002" ] }, { "id": "decree-territory-ref", "name": "territoryRef", "description": "Jurisdiction or sub-jurisdictional division to which the arrangement applies.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-020", "SRC-018" ] }, { "id": "decree-mirror-release", "name": "mirroredInRelease", "description": "Upstream reference-data release in which the change first appeared.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "legal-instrument-citation", "name": "Legal instrument citation record", "description": "Structured citation of the statute, directive, regulation or proclamation governing civil time for a territory, with official publication reference.", "media_or_form": [ "citation record", "link to official gazette entry" ], "serial": false, "identity_strategy": "Official instrument identifier from the issuing legal system as the authoritative master identifier; a Dimension UUID only where none exists.", "source_refs": [ "SRC-018", "SRC-020" ] }, { "id": "zone-change-notice", "name": "Zone change notice", "description": "Operational notice issued when a jurisdiction's zone or daylight rule changes, carrying announcement instant, effective instant and affected zone identifiers.", "media_or_form": [ "change notice record", "subscriber notification payload" ], "serial": true, "identity_strategy": "Sequential notice number within the Dimension, plus announcement instant and the upstream release identifier that carried the change.", "source_refs": [ "SRC-002", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "calendar-system", "name": "Calendar system", "description": "How days are grouped into months, years, eras and weeks, and how those systems are identified, structured and defaulted by territory.", "rationale": "Calendar choice is not presentation: recurrence expansion, era-based year numbering and week arithmetic produce different dates in different calendars, and the calendar identifier is normatively required by recurrence and timestamp annotation standards.", "source_refs": [ "SRC-011", "SRC-012", "SRC-013", "SRC-008", "SRC-006" ], "layers": [ { "id": "calendar-identity-and-structure", "name": "Calendar identity and structure", "description": "Registered calendar identifiers, their classification, intercalation and leap-month structure, and their deprecation and alias handling.", "source_refs": [ "SRC-013", "SRC-011", "SRC-008", "SRC-006" ], "findings": [ { "id": "calendar-system-definition", "name": "Calendar system identity, type and intercalation", "description": "A calendar system is identified by a registered key from the Unicode calendar registry, which recurrence and timestamp standards reference normatively. The registry distinguishes systems that differ only in determination method — tabular civil, tabular astronomical, Umm al-Qura and sighting-based Hijri variants — and marks deprecated keys with preferred replacements; leap months are denoted by an L suffix in recurrence contexts.", "source_refs": [ "SRC-013", "SRC-011", "SRC-008", "SRC-006" ], "questions": [ { "id": "csd-q1", "text": "Which registered calendar key identifies this system, and is that key current or deprecated in favour of another?", "kind": "identity", "answer_data": [ "calendar key", "registry version", "deprecation status", "preferred replacement key" ] }, { "id": "csd-q2", "text": "Is the system solar, lunar or lunisolar, and does it use intercalary days, intercalary months or both?", "kind": "classification", "answer_data": [ "astronomical class", "intercalation mechanism", "cycle length if tabular" ] }, { "id": "csd-q3", "text": "Where two keys describe the same tradition but differ in determination method, which one governs this record?", "kind": "decision", "answer_data": [ "selected key", "determination method (tabular, computed, observational)", "selection rationale", "authority for the method" ] }, { "id": "csd-q4", "text": "How are leap months represented and ordered when a date or recurrence falls in one?", "kind": "composition", "answer_data": [ "leap month notation", "position relative to the base month", "behaviour when the leap month is absent in a target year" ] }, { "id": "csd-q5", "text": "Which calendar is assumed when none is declared, and is that assumption territory-dependent?", "kind": "constraint", "answer_data": [ "default calendar key", "territory-based override source", "declaration requirement" ] }, { "id": "csd-q6", "text": "Can this calendar's dates be converted losslessly to and from the proleptic Gregorian representation used for storage?", "kind": "interoperability", "answer_data": [ "conversion library and version", "round-trip test result", "known lossy ranges" ] } ], "data_elements": [ { "id": "calendar-key", "name": "calendarKey", "description": "Registered calendar identifier used in annotations and recurrence scales.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-008" ] }, { "id": "calendar-class", "name": "astronomicalClass", "description": "Whether the calendar is solar, lunar or lunisolar.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-011" ] }, { "id": "calendar-determination-method", "name": "determinationMethod", "description": "Whether dates are fixed by tabular rule, astronomical computation or observation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "calendar-intercalation-rule", "name": "intercalationRule", "description": "Rule governing leap days or leap months.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-008" ] }, { "id": "calendar-deprecated-alias", "name": "deprecatedAlias", "description": "Superseded key that resolves to this calendar.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "calendar-registry-entry", "name": "Calendar registry entry", "description": "The adopted subset of the calendar registry, recording key, description, since-version and deprecation state for each calendar supported by the Dimension.", "media_or_form": [ "registry extract", "reference dataset" ], "serial": false, "identity_strategy": "Registry key as the governed global identifier, qualified by the registry release version the extract was taken from.", "source_refs": [ "SRC-013", "SRC-022" ] } ], "inline_only_rationale": null } ] }, { "id": "era-and-year-numbering", "name": "Era and year numbering", "description": "Eras within a calendar, their boundaries expressed in proleptic Gregorian terms, their ordering and inheritance, and the events that add or redefine them.", "source_refs": [ "SRC-011", "SRC-013", "SRC-017" ], "findings": [ { "id": "era-definition", "name": "Era boundaries, ordering and change events", "description": "An era is a named span within a calendar system with a mnemonic code, a numeric type for name lookup, and start and end dates expressed as proleptic Gregorian dates; eras are ordered by start date and may be inherited between related calendars. Eras are mutable reference data: a new era can be proclaimed and existing systems must absorb it.", "source_refs": [ "SRC-011", "SRC-013", "SRC-017" ], "questions": [ { "id": "ed-q1", "text": "Which era does a given date fall in, and how is the era boundary expressed unambiguously?", "kind": "temporal", "answer_data": [ "era code", "start date in proleptic Gregorian", "end date or open", "boundary inclusivity" ] }, { "id": "ed-q2", "text": "What identifies the era stably — the mnemonic code or the numeric type used for name lookup?", "kind": "identity", "answer_data": [ "era code", "numeric type", "alias codes", "stability note" ] }, { "id": "ed-q3", "text": "Does this calendar inherit eras from another calendar, and does that inheritance affect ordering?", "kind": "relationship", "answer_data": [ "inherited-from calendar key", "inheritance scope", "resulting ordered era list" ] }, { "id": "ed-q4", "text": "What process adds a new era, and what is the lead time between proclamation and effect?", "kind": "lifecycle", "answer_data": [ "proclaiming authority", "proclamation instant", "effective instant", "data release in which the era appeared" ] }, { "id": "ed-q5", "text": "Are year numbers within the era counted forward only, and how are dates before the calendar's epoch expressed?", "kind": "constraint", "answer_data": [ "year numbering direction", "proleptic extension policy", "representation for pre-epoch dates" ] } ], "data_elements": [ { "id": "era-code", "name": "eraCode", "description": "Mnemonic identifier for the era within its calendar system.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "era-start", "name": "eraStartDate", "description": "Era start expressed as a proleptic Gregorian date.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "era-end", "name": "eraEndDate", "description": "Era end expressed as a proleptic Gregorian date, absent for the current era.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "era-calendar-ref", "name": "calendarRef", "description": "The calendar system the era belongs to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-013" ] }, { "id": "era-year-in-era", "name": "yearInEra", "description": "Year number counted within the era.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-017" ] } ], "artifacts": [ { "id": "era-table", "name": "Era table", "description": "Ordered table of eras per calendar system with codes, numeric types, boundaries and inheritance.", "media_or_form": [ "reference table", "locale data extract" ], "serial": false, "identity_strategy": "Calendar key plus era code as compound authoritative identifier; the table carries the data release version it was derived from.", "source_refs": [ "SRC-011", "SRC-022" ] } ], "inline_only_rationale": null } ] }, { "id": "week-rules-and-territory-defaults", "name": "Week rules and territory defaults", "description": "Territory-scoped week data and calendar preference: first day of week, minimum days in the first week, weekend days, and the ISO week-date system.", "source_refs": [ "SRC-012", "SRC-011", "SRC-007", "SRC-013" ], "findings": [ { "id": "week-rule-set", "name": "Week rule set and weekend definition", "description": "First day of week, minimum days in the first week and weekend start and end are territory-scoped supplemental data, and can be overridden by an explicit region key. Week numbering under the ISO rules is itself a distinct registered calendar key, and recurrence rules carry their own week-start parameter that must not be silently inherited from locale.", "source_refs": [ "SRC-012", "SRC-011", "SRC-013", "SRC-007" ], "questions": [ { "id": "wrs-q1", "text": "Which territory's week data governs this computation, and how was that territory determined?", "kind": "spatial", "answer_data": [ "territory code", "determination path (explicit, region override, inferred)", "fallback territory" ] }, { "id": "wrs-q2", "text": "What are the first day of week, the minimum days in the first week and the weekend days for that territory?", "kind": "definition", "answer_data": [ "first day", "minimum days", "weekend start day", "weekend end day", "partial-day weekend note" ] }, { "id": "wrs-q3", "text": "Does week numbering follow the ISO week-date rules or the territory's own rules, and is that choice declared?", "kind": "classification", "answer_data": [ "week numbering system", "calendar key used", "declaration location" ] }, { "id": "wrs-q4", "text": "Is the week-start used in recurrence expansion the same as the locale week-start, and what happens if they differ?", "kind": "constraint", "answer_data": [ "recurrence week-start parameter", "locale week-start", "divergence handling", "example divergent result" ] }, { "id": "wrs-q5", "text": "How is a weekend that is not Saturday and Sunday represented in working-day calculations?", "kind": "interoperability", "answer_data": [ "weekend day set", "non-contiguous weekend support", "downstream consumers affected" ] } ], "data_elements": [ { "id": "first-day-of-week", "name": "firstDayOfWeek", "description": "Territory-scoped first day of the week.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "min-days-first-week", "name": "minDaysInFirstWeek", "description": "Minimum days that must fall in the first week of a year for it to count as week one.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "weekend-days", "name": "weekendDays", "description": "Set of days treated as the weekend in the territory.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "week-numbering-system", "name": "weekNumberingSystem", "description": "Which week-numbering rules apply, including the ISO week-date calendar key.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-012" ] }, { "id": "recurrence-week-start", "name": "recurrenceWeekStart", "description": "Week-start parameter used by a recurrence rule, independent of locale data.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "week-data-profile", "name": "Week data profile", "description": "Adopted territory-by-territory week and weekend data with declared overrides, used as the base of all working-day computation.", "media_or_form": [ "reference dataset", "supplemental data extract" ], "serial": false, "identity_strategy": "Territory code as key, qualified by the locale data release version; overrides carry an explicit owner and effective-from instant.", "source_refs": [ "SRC-012", "SRC-022" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "temporal-value-shapes", "name": "Temporal value shapes", "description": "The reusable, embeddable value objects this mix-in offers to every other model: instants, intervals, durations, granularity, indeterminacy and the binding contract that says how a temporal field is to be interpreted.", "rationale": "As a mix-in, the model's principal deliverable is a small set of precisely specified value shapes plus an explicit declaration of how each temporal field is bound. Without that declaration, floating, zoned and absolute times are indistinguishable in storage and silently produce wrong results.", "source_refs": [ "SRC-017", "SRC-007", "SRC-009", "SRC-005", "SRC-006", "SRC-024" ], "layers": [ { "id": "instant-interval-duration", "name": "Instant, interval and duration", "description": "The core value shapes and their arithmetic: zero-extent instants, proper intervals, exact versus nominal durations, and period forms.", "source_refs": [ "SRC-017", "SRC-007", "SRC-009", "SRC-005" ], "findings": [ { "id": "core-temporal-value-shapes", "name": "Core temporal value shapes and duration arithmetic", "description": "Temporal entities divide into instants of zero extent and intervals with extent, with proper intervals having distinct beginning and end. Periods are expressed either as start and end or as start and duration, and durations split into exact machine quantities and nominal calendar-clock descriptions whose length depends on where they are applied — a distinction that matters at transitions and at month boundaries.", "source_refs": [ "SRC-017", "SRC-007", "SRC-009" ], "questions": [ { "id": "ctvs-q1", "text": "Is this value an instant or an interval, and if an interval, are its endpoints distinct?", "kind": "definition", "answer_data": [ "shape class", "beginning value", "end value", "proper interval flag" ] }, { "id": "ctvs-q2", "text": "Is the interval expressed as start and end or as start and duration, and are the endpoints inclusive or exclusive?", "kind": "composition", "answer_data": [ "period form", "inclusivity of start", "inclusivity of end", "normalisation rule" ] }, { "id": "ctvs-q3", "text": "Is the duration an exact quantity or a nominal calendar description, and which units may it carry?", "kind": "measurement", "answer_data": [ "duration kind", "unit set", "sign convention", "normalisation policy" ] }, { "id": "ctvs-q4", "text": "How is a nominal duration added across a zone transition or a short or long month?", "kind": "constraint", "answer_data": [ "addition algorithm", "overflow clamping rule", "transition handling rule", "worked example" ] }, { "id": "ctvs-q5", "text": "Can an interval be unbounded at either end, and how is that represented distinctly from a missing value?", "kind": "exception", "answer_data": [ "unbounded start representation", "unbounded end representation", "null versus unbounded distinction" ] } ], "data_elements": [ { "id": "interval-start", "name": "start", "description": "Beginning of the interval, or the instant itself for a zero-extent value.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-007" ] }, { "id": "interval-end", "name": "end", "description": "End of the interval when expressed explicitly.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] }, { "id": "duration-value", "name": "duration", "description": "Length of the interval expressed as a duration when the end is not stated explicitly.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "duration-kind", "name": "durationKind", "description": "Whether the duration is an exact quantity or a nominal calendar-clock description.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-009" ] }, { "id": "endpoint-inclusivity", "name": "endpointInclusivity", "description": "Declared inclusivity of the interval endpoints.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "These are embedded value objects with no independent existence, custody or lifecycle: an interval or duration is always a property of some host record in a sibling model and is created, versioned and deleted with that host. Materialising them as standalone artifacts would create identifiers that no authority maintains and would invite reference drift; the model therefore ships them as inline shapes plus the binding declaration artifact in the sibling layer." } ] }, { "id": "granularity-and-indeterminacy", "name": "Granularity and indeterminacy", "description": "Declared precision, date-only versus date-time values, open-ended and partially known temporal statements, and how uncertainty is surfaced rather than fabricated.", "source_refs": [ "SRC-024", "SRC-017", "SRC-007", "SRC-009" ], "findings": [ { "id": "temporal-granularity-and-openness", "name": "Declared granularity, all-day values and open endpoints", "description": "A temporal statement carries a granularity that must be declared rather than inferred from the digits present, ranging from year through fractional second. Date-only values and all-day semantics are distinct from midnight-precision date-times, and an adopting profile must state which granularities and offset forms it supports.", "source_refs": [ "SRC-024", "SRC-017", "SRC-007", "SRC-009" ], "questions": [ { "id": "tgo-q1", "text": "What granularity does this value actually assert, and is that recorded separately from its serialised form?", "kind": "quality", "answer_data": [ "asserted granularity", "serialised digit count", "granularity field location" ] }, { "id": "tgo-q2", "text": "Is this a date-only or all-day value, and is it therefore zone-independent?", "kind": "classification", "answer_data": [ "all-day flag", "zone independence flag", "display rule" ] }, { "id": "tgo-q3", "text": "Which granularities and offset forms does this Dimension's adopted profile accept on input and emit on output?", "kind": "requirement", "answer_data": [ "accepted granularity set", "emitted granularity set", "offset forms accepted", "rejection behaviour" ] }, { "id": "tgo-q4", "text": "How is a value that is known only approximately, or only to a bounded range, represented without inventing precision?", "kind": "evidence", "answer_data": [ "representation chosen (bounded interval, granularity downgrade, qualifier)", "evidence basis", "confidence statement" ] }, { "id": "tgo-q5", "text": "Is comparison between values of different granularity defined, and what does it return when they overlap?", "kind": "validation", "answer_data": [ "comparison semantics", "indeterminate result handling", "test cases" ] } ], "data_elements": [ { "id": "granularity-code", "name": "granularity", "description": "Asserted precision of the value, from year to fractional second.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024", "SRC-017" ] }, { "id": "all-day-flag", "name": "isAllDay", "description": "Whether the value denotes a whole day rather than a point within it.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-007" ] }, { "id": "bounded-range", "name": "boundedRange", "description": "Interval within which the true value is asserted to lie, used instead of false precision.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "openness-flag", "name": "openEndpoint", "description": "Marks a start or end as open or unbounded rather than unknown.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-007" ] } ], "artifacts": [ { "id": "temporal-precision-profile", "name": "Temporal precision profile", "description": "The Dimension's declaration of accepted and emitted granularities, all-day semantics, and representation of bounded or open values.", "media_or_form": [ "profile specification", "validation ruleset" ], "serial": false, "identity_strategy": "Dimension-assigned identifier and semantic version; effective-from and effective-until instants recorded on each version.", "source_refs": [ "SRC-024", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "temporal-binding-contract", "name": "Temporal binding contract", "description": "The per-field declaration of whether a temporal value is floating, zoned or absolute, and which companion fields must accompany it.", "source_refs": [ "SRC-007", "SRC-009", "SRC-006", "SRC-005" ], "findings": [ { "id": "temporal-binding-declaration", "name": "Floating, zoned and absolute binding", "description": "Three bindings exist and must be distinguished per field: a floating local value that occurs at the same wall-clock reading everywhere, a local value bound to a named zone, and an absolute instant with an explicit offset or Z. The binding determines which companion fields are mandatory and which operations are valid, and it is a semantic property of the field, not of its serialisation.", "source_refs": [ "SRC-007", "SRC-009", "SRC-006", "SRC-005" ], "questions": [ { "id": "tbd-q1", "text": "Which binding does this field use, and where is that binding declared for machine consumption?", "kind": "requirement", "answer_data": [ "binding code", "declaration location", "default binding for the model" ] }, { "id": "tbd-q2", "text": "Which companion fields are mandatory for this binding — zone identifier, calendar key, granularity, resolved offset?", "kind": "constraint", "answer_data": [ "required companion field list", "validation rule", "error code on omission" ] }, { "id": "tbd-q3", "text": "Is a floating value ever silently converted to an absolute instant on storage or transport?", "kind": "validation", "answer_data": [ "conversion audit result", "conversion points found", "remediation" ] }, { "id": "tbd-q4", "text": "When the value crosses a system boundary, which annotations travel with it and which are critical?", "kind": "interoperability", "answer_data": [ "annotations carried", "criticality flags", "receiver obligations", "behaviour when annotations are dropped" ] }, { "id": "tbd-q5", "text": "Which binding should be chosen for a newly modelled field, and on what test?", "kind": "decision", "answer_data": [ "decision test (does the moment shift with the observer)", "chosen binding", "reviewer", "rationale" ] } ], "data_elements": [ { "id": "binding-mode", "name": "bindingMode", "description": "Declared binding: floating, zoned or absolute.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "binding-zone-ref", "name": "zoneRef", "description": "Zone identifier required when the binding is zoned.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "binding-calendar-ref", "name": "calendarRef", "description": "Calendar key required when the field's meaning depends on a non-default calendar.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-013" ] }, { "id": "binding-criticality", "name": "annotationCriticality", "description": "Whether accompanying annotations must be honoured or may be ignored by a receiver.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "field-binding-declaration", "name": "Field binding declaration", "description": "Machine-readable register of every temporal field exposed by the adopting Dimension with its binding, companion field requirements and validation rules.", "media_or_form": [ "field register", "schema annotation set" ], "serial": false, "identity_strategy": "Fully qualified field path within the owning model as the master identifier; register version tracks additions and binding changes, which are breaking.", "source_refs": [ "SRC-007", "SRC-009", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "recurrence-and-scheduling-rules", "name": "Recurrence and scheduling rules", "description": "Rules that generate sets of dates or instants, their exceptions and overrides, and their behaviour under non-Gregorian calendar scales.", "rationale": "Recurrence is where calendar, zone and week data combine and where most silent divergence between implementations appears. Its semantics are normatively specified and must be modelled separately from the values it generates.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-013" ], "layers": [ { "id": "recurrence-rule-semantics", "name": "Recurrence rule semantics", "description": "The structure and evaluation of a recurrence rule: frequency, interval, by-part filters, week start, and the bounds that terminate the set.", "source_refs": [ "SRC-007", "SRC-009", "SRC-012" ], "findings": [ { "id": "recurrence-rule", "name": "Recurrence rule structure and expansion", "description": "A recurrence rule has a required frequency and optional interval, by-part filters, week start and a terminating count or until value, with count and until mutually exclusive. Expansion is anchored on the series start value, and by-position selection applies after the other filters, so an unanchored or unbounded rule is not evaluable without an explicit expansion window.", "source_refs": [ "SRC-007", "SRC-009", "SRC-012" ], "questions": [ { "id": "rr-q1", "text": "What frequency, interval and by-part filters define this rule, and in what order are they applied?", "kind": "definition", "answer_data": [ "frequency", "interval", "by-part filter values", "evaluation order", "by-position selection" ] }, { "id": "rr-q2", "text": "What anchors the expansion, and does the anchor itself belong to the generated set?", "kind": "composition", "answer_data": [ "anchor value", "anchor inclusion rule", "anchor binding mode" ] }, { "id": "rr-q3", "text": "Is the rule bounded by a count or by an until value, and does the until value match the anchor's value type and binding?", "kind": "constraint", "answer_data": [ "count", "until value", "value type match check", "mutual exclusivity check" ] }, { "id": "rr-q4", "text": "For an unbounded rule, what expansion window is used and who sets it?", "kind": "process", "answer_data": [ "window start", "window end", "window owner", "re-expansion cadence" ] }, { "id": "rr-q5", "text": "Which week start applies, and how does changing it alter the generated set?", "kind": "measurement", "answer_data": [ "week start value", "affected by-part filters", "divergence example" ] }, { "id": "rr-q6", "text": "When the underlying zone rules change, are previously expanded instances recomputed or frozen?", "kind": "lifecycle", "answer_data": [ "recomputation policy", "frozen instance marker", "notification to dependents" ] } ], "data_elements": [ { "id": "recur-frequency", "name": "frequency", "description": "Required base frequency of the recurrence.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "recur-interval", "name": "interval", "description": "How many frequency units separate occurrences.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "recur-by-parts", "name": "byParts", "description": "Filter components such as by-day, by-month-day, by-month and by-position.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "recur-until", "name": "until", "description": "Inclusive upper bound of the recurrence set.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "recur-count", "name": "count", "description": "Number of occurrences generated, mutually exclusive with the until bound.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "recur-anchor", "name": "anchorValue", "description": "The series start from which expansion proceeds.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] } ], "artifacts": [ { "id": "recurrence-rule-expression", "name": "Recurrence rule expression", "description": "The stored, portable expression of the rule together with its anchor, binding mode and expansion window.", "media_or_form": [ "rule expression string", "structured rule object" ], "serial": false, "identity_strategy": "Identified by the owning series identifier plus rule sequence position; a Dimension UUID is assigned where the rule is reused standalone.", "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "expanded-occurrence-set", "name": "Expanded occurrence set", "description": "Materialised occurrences for a stated window, recording the zone and calendar data releases used so the expansion is reproducible.", "media_or_form": [ "occurrence list", "materialised calendar feed" ], "serial": true, "identity_strategy": "Series identifier plus window bounds plus the reference-data release identifiers used; regenerated sets are new artifacts, not edits.", "source_refs": [ "SRC-010", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "recurrence-exceptions-and-calendar-scale", "name": "Recurrence exceptions and calendar scale", "description": "Excluded and added dates, per-occurrence overrides and their identity, and expansion under a non-Gregorian calendar scale with skip behaviour.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-013" ], "findings": [ { "id": "recurrence-exception-and-rscale", "name": "Exceptions, overrides and non-Gregorian expansion", "description": "A recurrence set is modified by excluded dates, additional dates and per-occurrence overrides keyed by the occurrence's original value; an override key that matches no generated occurrence yields an extra occurrence rather than an error. When expansion runs on a non-Gregorian scale, an explicit scale parameter selects the calendar and a skip parameter determines the treatment of dates that do not exist in the target year.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-013" ], "questions": [ { "id": "rer-q1", "text": "How is a single occurrence identified so that an override or cancellation can target it unambiguously?", "kind": "identity", "answer_data": [ "occurrence key value", "key binding mode", "behaviour when the key matches no occurrence" ] }, { "id": "rer-q2", "text": "Which dates are excluded and which are added outside the rule, and who authorised each?", "kind": "exception", "answer_data": [ "excluded date list", "added date list", "authorising actor", "reason" ] }, { "id": "rer-q3", "text": "Which calendar scale governs expansion, and is it declared explicitly rather than inherited?", "kind": "classification", "answer_data": [ "recurrence scale key", "declaration location", "default when absent" ] }, { "id": "rer-q4", "text": "What happens when a generated date does not exist in the target year — omit, move backward or move forward?", "kind": "constraint", "answer_data": [ "skip behaviour", "default skip value", "worked example for a leap-day rule" ] }, { "id": "rer-q5", "text": "Do all consuming implementations expand this rule to the same set, and how was that verified?", "kind": "interoperability", "answer_data": [ "implementations tested", "test vectors", "divergences found", "resolution" ] }, { "id": "rer-q6", "text": "Are overrides preserved when the base rule is edited, and how are orphaned overrides detected?", "kind": "validation", "answer_data": [ "override reconciliation rule", "orphan detection check", "reporting surface" ] } ], "data_elements": [ { "id": "excluded-dates", "name": "excludedDates", "description": "Dates removed from the generated set.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "added-dates", "name": "addedDates", "description": "Dates added to the set outside the rule.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "occurrence-overrides", "name": "occurrenceOverrides", "description": "Map from an occurrence key to a patch of that occurrence's properties, including cancellation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "recurrence-scale", "name": "recurrenceScale", "description": "Registered calendar key governing expansion.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-013" ] }, { "id": "skip-behaviour", "name": "skipBehaviour", "description": "Treatment of generated dates that do not exist in the target year or month.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "leap-month-marker", "name": "leapMonthMarker", "description": "Notation identifying a leap month in by-month filters.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "recurrence-override-set", "name": "Recurrence override set", "description": "The stored collection of exclusions, additions and per-occurrence patches for a series, with authorisation metadata.", "media_or_form": [ "override collection", "patch document set" ], "serial": false, "identity_strategy": "Series identifier plus occurrence key; each override records the actor and the instant at which it was applied.", "source_refs": [ "SRC-007", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "observance-and-working-day", "name": "Observance and working day", "description": "Days that carry civil or cultural weight: proclaimed public holidays, religious and cultural observances, and the working-day calendars and date-adjustment conventions built from them.", "rationale": "Holiday and observance data has a different authority model from zone data — it is proclaimed per jurisdiction, published on a rolling horizon and frequently amended — and it feeds date arithmetic that has direct legal and financial consequence.", "source_refs": [ "SRC-019", "SRC-018", "SRC-020", "SRC-021", "SRC-012", "SRC-013" ], "layers": [ { "id": "public-holiday-proclamation", "name": "Public holiday proclamation", "description": "Holidays declared by a competent authority for a jurisdiction or division, their day-off status, substitute days and publication horizon.", "source_refs": [ "SRC-019", "SRC-020", "SRC-018" ], "findings": [ { "id": "public-holiday-instance", "name": "Proclaimed holiday instance and substitution", "description": "A public holiday is a dated instance scoped to a jurisdictional division, carrying a title, the date actually observed, and notes recording substitution where the nominal date falls on a non-working day. Authoritative feeds publish a bounded forward horizon and include one-off holidays, so a holiday set is a per-jurisdiction, per-year assertion rather than a permanent rule.", "source_refs": [ "SRC-019", "SRC-020", "SRC-018" ], "questions": [ { "id": "phi-q1", "text": "Which jurisdiction or sub-jurisdictional division does this holiday apply to, and do divisions within the same state differ?", "kind": "spatial", "answer_data": [ "division identifier", "parent jurisdiction", "list of divisions where the holiday does not apply" ] }, { "id": "phi-q2", "text": "Which authority proclaimed the holiday, and under what instrument?", "kind": "authority", "answer_data": [ "proclaiming authority", "instrument type", "instrument identifier", "publication reference" ] }, { "id": "phi-q3", "text": "Is the observed date the nominal date or a substitute, and what rule produced the substitution?", "kind": "composition", "answer_data": [ "nominal date", "observed date", "substitution rule", "substitution note text" ] }, { "id": "phi-q4", "text": "Does the holiday confer a non-working day, and for whom — all employers, public sector only, or specific sectors?", "kind": "classification", "answer_data": [ "day-off status", "scope of application", "sector exceptions" ] }, { "id": "phi-q5", "text": "How far forward is the holiday calendar authoritatively published, and what is done beyond that horizon?", "kind": "temporal", "answer_data": [ "published horizon end date", "beyond-horizon policy", "estimated versus confirmed marker" ] }, { "id": "phi-q6", "text": "How are one-off, rescinded or retroactively declared holidays recorded without corrupting historical calculations?", "kind": "lifecycle", "answer_data": [ "holiday status (recurring, one-off, rescinded)", "effective instant", "supersedes reference", "recalculation policy for affected records" ] } ], "data_elements": [ { "id": "holiday-title", "name": "title", "description": "Official name of the holiday as published by the authority.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "holiday-observed-date", "name": "observedDate", "description": "The date actually observed, which may be a substitute for the nominal date.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "holiday-nominal-date", "name": "nominalDate", "description": "The date the holiday nominally falls on before substitution.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "holiday-division-ref", "name": "divisionRef", "description": "Jurisdictional division to which the holiday applies.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-019", "SRC-020" ] }, { "id": "holiday-day-off-status", "name": "dayOffStatus", "description": "Whether and for whom the day is a non-working day.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "holiday-notes", "name": "notes", "description": "Authority-supplied annotation such as a substitution statement.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "holiday-instrument-ref", "name": "proclamationRef", "description": "Reference to the proclaiming instrument.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-018" ] } ], "artifacts": [ { "id": "holiday-calendar-publication", "name": "Holiday calendar publication", "description": "The authority's published holiday set for a jurisdiction over a stated horizon, retrieved and retained as evidence for downstream computation.", "media_or_form": [ "authority data feed snapshot", "official gazette listing", "machine-readable calendar file" ], "serial": true, "identity_strategy": "Publishing authority plus jurisdiction plus retrieval instant; where the authority assigns a publication reference, that reference is the master identifier and the retrieval instant is recorded separately.", "source_refs": [ "SRC-019" ] }, { "id": "holiday-proclamation-instrument", "name": "Holiday proclamation instrument", "description": "The legal instrument creating, moving or rescinding a public holiday.", "media_or_form": [ "proclamation document", "statutory instrument", "gazette notice" ], "serial": false, "identity_strategy": "Official instrument identifier from the issuing legal system; effective instant and announcement instant recorded separately.", "source_refs": [ "SRC-020", "SRC-018" ] } ], "inline_only_rationale": null } ] }, { "id": "cultural-religious-observance", "name": "Cultural and religious observance", "description": "Recurring days of cultural or religious significance, the calendars and methods that determine them, and their variation by community and locality.", "source_refs": [ "SRC-013", "SRC-011", "SRC-008" ], "findings": [ { "id": "observance-definition", "name": "Observance determination method and local variation", "description": "An observance is a recurring day whose date is determined within a specific calendar system by a specific method — tabular rule, astronomical computation or local observation. The calendar registry itself distinguishes variants of the same tradition by determination method, which is direct evidence that a single canonical date frequently does not exist and that method and community must be recorded alongside the date.", "source_refs": [ "SRC-013", "SRC-011", "SRC-008" ], "questions": [ { "id": "od-q1", "text": "Within which calendar system is this observance computed, and by which determination method?", "kind": "definition", "answer_data": [ "calendar key", "determination method", "computation reference" ] }, { "id": "od-q2", "text": "Is the observance fixed in its own calendar, movable, or dependent on observation that cannot be predicted?", "kind": "classification", "answer_data": [ "movability class", "predictability horizon", "fallback estimate rule" ] }, { "id": "od-q3", "text": "Which community or authority determines the date, and do communities in the same territory differ?", "kind": "provenance", "answer_data": [ "determining body", "tradition or community", "known divergent determinations", "territory scope" ] }, { "id": "od-q4", "text": "What evidence supports the date asserted for a specific year, and when was it confirmed?", "kind": "evidence", "answer_data": [ "announcement source", "confirmation instant", "provisional versus confirmed status" ] }, { "id": "od-q5", "text": "Does the observance carry any civil effect, and where does that effect come from?", "kind": "authority", "answer_data": [ "civil effect flag", "linked public holiday reference", "instrument creating the effect" ] }, { "id": "od-q6", "text": "How does the system behave when a provisional date is later corrected?", "kind": "exception", "answer_data": [ "correction event record", "downstream notification", "recomputation scope" ] } ], "data_elements": [ { "id": "observance-name", "name": "name", "description": "Name of the observance, preserving the official or traditional form.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "observance-calendar-ref", "name": "computedInCalendar", "description": "Calendar system in which the observance's date is defined.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-008" ] }, { "id": "observance-method", "name": "determinationMethod", "description": "Tabular, computed or observational determination of the date.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "observance-tradition", "name": "tradition", "description": "Community or tradition whose determination governs.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "observance-confirmation-status", "name": "confirmationStatus", "description": "Whether a year's date is provisional or confirmed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "observance-movable-flag", "name": "isMovable", "description": "Whether the observance moves relative to the Gregorian calendar.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-011" ] } ], "artifacts": [ { "id": "observance-determination-record", "name": "Observance determination record", "description": "Per-year record of an observance's determined date, the determining body, the method applied and the confirmation status.", "media_or_form": [ "determination record", "community announcement capture" ], "serial": true, "identity_strategy": "Observance identifier plus year plus determining community; the determining body's own announcement reference is used as master identifier where one exists.", "source_refs": [ "SRC-013", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "working-day-and-date-adjustment", "name": "Working day and date adjustment", "description": "Composition of weekend rules and holiday sets into working-day calendars, and the conventions that move a date off a non-working day.", "source_refs": [ "SRC-021", "SRC-012", "SRC-019", "SRC-007" ], "findings": [ { "id": "working-day-calendar", "name": "Working-day calendar and business day convention", "description": "A working-day calendar is a composition of a territory's weekend rule and a jurisdiction's holiday set over a stated period, addressed by a named centre. A date-adjustment convention then determines how a date falling on a non-working day is moved; the standard conventions are following, modified following, preceding, modified preceding, nearest, a floating-rate variant, and no adjustment.", "source_refs": [ "SRC-021", "SRC-012", "SRC-019" ], "questions": [ { "id": "wdc-q1", "text": "Which weekend rule and which holiday sets compose this calendar, and over what period is it valid?", "kind": "composition", "answer_data": [ "weekend rule reference", "holiday set references", "valid-from date", "valid-until date" ] }, { "id": "wdc-q2", "text": "Which named centre or centres apply, and when several apply, is a date a working day only if it is one in all of them?", "kind": "process", "answer_data": [ "centre identifiers", "combination rule (intersection or union)", "worked example" ] }, { "id": "wdc-q3", "text": "Which adjustment convention applies, and does it respect month boundaries?", "kind": "decision", "answer_data": [ "convention code", "month-boundary behaviour", "direction of first attempt" ] }, { "id": "wdc-q4", "text": "How are day counts and deadlines computed — calendar days, working days, or working days with a cut-off time?", "kind": "measurement", "answer_data": [ "counting basis", "cut-off time and its binding mode", "inclusivity of the first and last day" ] }, { "id": "wdc-q5", "text": "What happens to previously computed deadlines when a holiday is added or moved after the fact?", "kind": "exception", "answer_data": [ "recomputation policy", "frozen result marker", "notification obligation", "legal review trigger" ] }, { "id": "wdc-q6", "text": "Which reference-data releases were used to build this calendar, so a past computation can be reproduced exactly?", "kind": "provenance", "answer_data": [ "holiday feed snapshot reference", "week data release", "zone data release", "build instant" ] } ], "data_elements": [ { "id": "centre-code", "name": "businessCentreCode", "description": "Named centre whose working-day calendar applies.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-021" ] }, { "id": "adjustment-convention", "name": "dateAdjustmentConvention", "description": "Convention applied when a date falls on a non-working day.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021" ] }, { "id": "non-working-day-set", "name": "nonWorkingDays", "description": "Resolved set of dates that are not working days for the centre over the validity period.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-019", "SRC-012" ] }, { "id": "counting-basis", "name": "countingBasis", "description": "Whether elapsed time is counted in calendar days or working days.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021" ] }, { "id": "cutoff-time", "name": "cutoffTime", "description": "Time of day after which activity counts against the next working day, with its binding mode.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-021" ] } ], "artifacts": [ { "id": "working-day-calendar-projection", "name": "Working-day calendar projection", "description": "Materialised list of working and non-working days for a centre and period, with the composing inputs and their release identifiers recorded.", "media_or_form": [ "date list", "tabular calendar export", "calendar feed" ], "serial": true, "identity_strategy": "Centre code plus period bounds plus build instant and the identifiers of every input release; regenerated calendars are new artifacts retained alongside their predecessors.", "source_refs": [ "SRC-021", "SRC-019", "SRC-012" ] }, { "id": "date-adjustment-rule", "name": "Date adjustment rule", "description": "The declared convention, centre combination rule and counting basis applied by a given process or contract.", "media_or_form": [ "rule record", "configuration entry" ], "serial": false, "identity_strategy": "Owning process or contract identifier plus rule name; convention values are taken from the governed enumeration rather than free text.", "source_refs": [ "SRC-021" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "reference-data-governance", "name": "Reference data governance and distribution", "description": "How temporal reference data is versioned, signed, distributed, checked for freshness, and how its known inaccuracies and conflicts are recorded.", "rationale": "Every computation in this model is only as good as the release of zone, calendar, leap and holiday data it used. The upstream standards themselves specify versioning, expiry and change detection, and the primary maintainers publish explicit accuracy caveats that must be carried forward rather than hidden.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010", "SRC-016", "SRC-022", "SRC-015" ], "layers": [ { "id": "version-release-and-freshness", "name": "Version, release and freshness", "description": "Release identity and cadence, signing, monolithic versus incremental versioning, change detection and expiry of perishable data.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-016", "SRC-022" ], "findings": [ { "id": "reference-data-release", "name": "Release identity, signing and freshness obligation", "description": "Temporal reference data is released as identified versions on an irregular, event-driven cadence — the zone database is released roughly twenty times a year and releases should be cryptographically signed. Distribution services support monolithic or per-zone versioning with synchronisation tokens and conditional requests, and some datasets carry hard expiry, so pinning a release and proving its freshness is a first-class obligation.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-016", "SRC-022" ], "questions": [ { "id": "rdr-q1", "text": "Which release of each reference dataset is currently pinned, and where is the pin recorded?", "kind": "identity", "answer_data": [ "zone data release identifier", "locale data release identifier", "leap table update marker", "holiday feed snapshot reference", "pin location" ] }, { "id": "rdr-q2", "text": "Was the release signature or checksum verified before adoption, and by whom?", "kind": "security", "answer_data": [ "verification method", "key or checksum reference", "verifier", "verification instant" ] }, { "id": "rdr-q3", "text": "How is a change upstream detected, and how quickly must it be adopted?", "kind": "lifecycle", "answer_data": [ "change detection mechanism", "polling or subscription cadence", "maximum adoption lag", "escalation path for urgent zone changes" ] }, { "id": "rdr-q4", "text": "Does any pinned dataset carry an expiry, and what is the behaviour after that instant?", "kind": "temporal", "answer_data": [ "expiry instant per dataset", "pre-expiry warning threshold", "post-expiry behaviour" ] }, { "id": "rdr-q5", "text": "Is versioning monolithic across all zones or independent per zone, and does the consumer handle both?", "kind": "interoperability", "answer_data": [ "versioning model", "per-zone version support", "synchronisation token handling" ] }, { "id": "rdr-q6", "text": "Can a historical computation be reproduced by re-pinning the releases it originally used?", "kind": "validation", "answer_data": [ "retained release archive", "reproduction test result", "gaps in retained releases" ] } ], "data_elements": [ { "id": "release-identifier", "name": "releaseIdentifier", "description": "Publisher's identifier for the adopted release of a reference dataset.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-022" ] }, { "id": "release-instant", "name": "releasedAt", "description": "Instant at which the publisher issued the release.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-022" ] }, { "id": "adoption-instant", "name": "adoptedAt", "description": "Instant at which the adopting Dimension put the release into effect, recorded separately from the release instant.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "integrity-evidence", "name": "integrityEvidence", "description": "Signature, checksum or entity tag recorded as proof of the artifact received.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "dataset-expiry", "name": "expiresAt", "description": "Instant after which the dataset must not be relied upon.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-010" ] }, { "id": "sync-token", "name": "synchronisationToken", "description": "Opaque token used to request only changes since the last retrieval.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "release-manifest", "name": "Reference data release manifest", "description": "The set of pinned releases with publisher, release identifier, release instant, adoption instant and integrity evidence for every temporal dataset in use.", "media_or_form": [ "manifest record", "dependency lock entry" ], "serial": false, "identity_strategy": "Dimension-assigned identifier plus manifest version; each entry keyed by publisher plus that publisher's release identifier as the authoritative master identifier.", "source_refs": [ "SRC-001", "SRC-022", "SRC-010" ] }, { "id": "freshness-attestation", "name": "Freshness attestation", "description": "Periodic record that each pinned dataset was checked, is unexpired, and is at or within the permitted lag of the current upstream release.", "media_or_form": [ "attestation record", "monitoring check result" ], "serial": true, "identity_strategy": "Sequential attestation number plus the check instant; supersedes the previous attestation without deleting it.", "source_refs": [ "SRC-016", "SRC-010", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "provenance-conflict-and-quality", "name": "Provenance, conflict and quality", "description": "Recording where a temporal fact came from, how reliable it is, where authoritative sources disagree, and how corrections propagate.", "source_refs": [ "SRC-003", "SRC-002", "SRC-011", "SRC-015", "SRC-010" ], "findings": [ { "id": "provenance-and-known-inaccuracy", "name": "Provenance, declared inaccuracy and conflict handling", "description": "The maintainers of the primary zone dataset state plainly that many pre-1970 and future timestamps are wrong or misleading, that some entries derive from unreliable sources, and that transitions were often gradual rather than instantaneous. A downstream model must therefore carry an evidence class and known-inaccuracy marker with each fact, and must record where the stability-oriented locale layer and the volatile upstream layer disagree.", "source_refs": [ "SRC-003", "SRC-002", "SRC-011", "SRC-015" ], "questions": [ { "id": "pki-q1", "text": "What is the evidence class of this temporal fact — legal instrument, authority publication, mirrored consensus, or reconstruction?", "kind": "evidence", "answer_data": [ "evidence class", "citation", "reconstruction method if applicable" ] }, { "id": "pki-q2", "text": "Is the fact within a range the upstream maintainer declares unreliable, and is that warning propagated to consumers?", "kind": "quality", "answer_data": [ "reliability range flag", "maintainer caveat text", "consumer-facing warning surface" ] }, { "id": "pki-q3", "text": "Where two authoritative sources disagree, which one governs here and on what documented basis?", "kind": "decision", "answer_data": [ "conflicting sources", "governing source", "decision rationale", "decision maker", "review date" ] }, { "id": "pki-q4", "text": "When an upstream correction changes a historical value, what is done with results already published from the old value?", "kind": "exception", "answer_data": [ "correction event record", "affected output inventory", "reissue or annotate policy", "notification obligation" ] }, { "id": "pki-q5", "text": "Who is accountable for the accuracy of each class of temporal fact in this Dimension?", "kind": "ownership", "answer_data": [ "fact class", "accountable role", "review cadence", "escalation contact" ] }, { "id": "pki-q6", "text": "Is the provenance chain from legal instrument to mirrored dataset to local record complete and traversable?", "kind": "provenance", "answer_data": [ "chain completeness check", "missing links", "remediation action" ] } ], "data_elements": [ { "id": "evidence-class", "name": "evidenceClass", "description": "Strength and kind of support behind a temporal fact.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-002" ] }, { "id": "known-inaccuracy-flag", "name": "knownInaccuracyFlag", "description": "Marks facts falling in ranges the upstream maintainer declares unreliable.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "conflict-record", "name": "conflictRecord", "description": "Statement of a disagreement between sources, the governing choice and its basis.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-003" ] }, { "id": "correction-event", "name": "correctionEvent", "description": "Record of an upstream or local correction, with event instant and observation instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-015" ] }, { "id": "accountable-role", "name": "accountableRole", "description": "Role accountable for the accuracy of the fact class.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "data-quality-caveat-register", "name": "Data quality caveat register", "description": "Register of declared unreliable ranges, source conflicts, governing choices and open corrections for temporal reference data.", "media_or_form": [ "register record set", "published caveat note" ], "serial": false, "identity_strategy": "Dimension-assigned entry identifier; each entry cites the upstream caveat or conflicting sources and records opened, reviewed and closed instants.", "source_refs": [ "SRC-003", "SRC-011", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-local-to-instant", "name": "Resolve local time to instant", "description": "Convert a wall-clock local date-time in a named zone to an instant on the reference scale, applying the declared gap and overlap policy and recording the resolved offset.", "inputs": [ "local date-time value", "zone identifier", "gap policy", "overlap policy", "pinned zone data release" ], "outputs": [ "instant with explicit offset", "resolved offset", "anomaly classification (none, gap, overlap)" ], "preconditions": [ "Zone identifier resolves to a canonical zone in the pinned release", "Requested instant lies within the release's asserted validity bound or a projection rule is available" ], "effects": [ "Resolved offset and the zone data release identifier are persisted with the value so the resolution is reproducible", "Anomalies are surfaced rather than silently defaulted" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-007", "SRC-006" ] }, { "id": "resolve-instant-to-local", "name": "Render instant as local civil time", "description": "Project an instant onto a named zone and calendar to obtain the civil date-time, era and designation in force at that instant.", "inputs": [ "instant", "zone identifier", "calendar key", "week data territory" ], "outputs": [ "local date-time", "offset in force", "daylight indicator", "era and year-in-era", "designation" ], "preconditions": [ "Calendar key is current and not deprecated in the pinned registry extract", "Zone data covers the requested instant" ], "effects": [ "Emits the calendar and zone annotations alongside the value when crossing a system boundary" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-011", "SRC-013" ] }, { "id": "expand-recurrence", "name": "Expand recurrence set", "description": "Generate the occurrence set for a recurrence rule over a bounded window, applying by-part filters in specified order, week start, calendar scale, skip behaviour, exclusions, additions and overrides.", "inputs": [ "recurrence rule expression", "anchor value and binding mode", "expansion window", "recurrence scale", "skip behaviour", "exclusion and addition lists", "override map" ], "outputs": [ "ordered occurrence list", "per-occurrence keys", "list of skipped or shifted dates with reason" ], "preconditions": [ "Anchor value is present and its binding mode is declared", "Count and until bounds are not both present", "Window is bounded when the rule is otherwise infinite" ], "effects": [ "Produces a materialised occurrence set stamped with the reference-data releases used", "Reports override keys that matched no generated occurrence" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-009" ] }, { "id": "convert-calendar-date", "name": "Convert between calendar systems", "description": "Convert a date between registered calendar systems, resolving eras, leap months and intercalation, and reporting any loss.", "inputs": [ "source calendar key", "source date with era", "target calendar key" ], "outputs": [ "target calendar date with era", "leap month marker where applicable", "loss report" ], "preconditions": [ "Both calendar keys exist in the pinned registry extract", "Determination method is declared for observational calendars" ], "effects": [ "Records the determination method and registry release used for the conversion" ], "source_refs": [ "SRC-011", "SRC-013", "SRC-008" ] }, { "id": "compute-holiday-set", "name": "Compute holiday set for jurisdiction and period", "description": "Assemble the authoritative holiday set for a jurisdictional division over a period from proclamations, published feeds and observance determinations, marking substitutions and confirmation status.", "inputs": [ "division identifier", "period bounds", "holiday feed snapshots", "observance determination records" ], "outputs": [ "dated holiday list with day-off status", "substitution annotations", "beyond-horizon marker for uncovered dates" ], "preconditions": [ "At least one authoritative feed or instrument covers the division", "Period start and end are declared with inclusivity" ], "effects": [ "Marks dates beyond the authority's published horizon as unconfirmed rather than absent", "Retains the feed snapshot as evidence" ], "source_refs": [ "SRC-019", "SRC-020", "SRC-018", "SRC-013" ] }, { "id": "build-working-day-calendar", "name": "Build working-day calendar", "description": "Compose a territory weekend rule with one or more holiday sets to produce the working and non-working days for a named centre over a period.", "inputs": [ "business centre code", "territory week data", "holiday sets", "centre combination rule", "period bounds" ], "outputs": [ "working day list", "non-working day list with reason per date", "input release manifest" ], "preconditions": [ "Week data exists for the territory or an explicit override is declared", "Holiday sets cover the whole period or the shortfall is reported" ], "effects": [ "Emits a serial projection artifact retained alongside its predecessors for reproducibility" ], "source_refs": [ "SRC-012", "SRC-019", "SRC-021" ] }, { "id": "adjust-date-to-business-day", "name": "Adjust date to a business day", "description": "Move a date that falls on a non-working day according to a named adjustment convention, respecting month-boundary behaviour where the convention requires it.", "inputs": [ "unadjusted date", "working-day calendar", "adjustment convention code" ], "outputs": [ "adjusted date", "adjustment applied (none, forward, backward)", "month-boundary reversal flag" ], "preconditions": [ "Convention code is drawn from the governed enumeration", "Working-day calendar covers the candidate dates in both directions" ], "effects": [ "Records the convention and calendar release used so the adjustment can be re-derived" ], "source_refs": [ "SRC-021", "SRC-019", "SRC-012" ] }, { "id": "compute-elapsed-and-deadline", "name": "Compute elapsed time and deadline", "description": "Compute an elapsed duration or a deadline instant using a declared counting basis, cut-off time and endpoint inclusivity, distinguishing exact from nominal duration arithmetic.", "inputs": [ "start value", "duration or target count", "counting basis", "working-day calendar", "cut-off time and binding mode", "endpoint inclusivity" ], "outputs": [ "result instant or date", "counting trace", "clamping or transition adjustments applied" ], "preconditions": [ "Duration kind is declared as exact or nominal", "Start value binding mode is declared" ], "effects": [ "Nominal arithmetic across zone transitions and short months is applied by the declared algorithm rather than by implementation default" ], "source_refs": [ "SRC-007", "SRC-009", "SRC-017", "SRC-021" ] }, { "id": "validate-temporal-value", "name": "Validate temporal value against profile", "description": "Check a temporal value against the Dimension's timestamp, precision and binding profiles, rejecting unqualified local times and unsupported granularities.", "inputs": [ "temporal value", "field binding declaration", "timestamp conformance profile", "temporal precision profile" ], "outputs": [ "validation verdict", "violation list with error codes", "normalised value where normalisation is permitted" ], "preconditions": [ "The field has an entry in the binding declaration register" ], "effects": [ "Blocks ingestion of values lacking a required offset, zone, calendar key or granularity" ], "source_refs": [ "SRC-005", "SRC-006", "SRC-024", "SRC-009" ] }, { "id": "detect-reference-data-change", "name": "Detect and classify reference data change", "description": "Compare a newly published reference-data release with the pinned release, classify each change, and identify affected stored values and computations.", "inputs": [ "pinned release identifiers", "candidate release identifiers", "synchronisation token or entity tags", "inventory of stored temporal values" ], "outputs": [ "change list classified by type (new zone, relink, offset rule change, holiday added or moved, era added, leap decision)", "impact set", "recommended adoption window" ], "preconditions": [ "Both releases are retained and verifiable", "Stored values record the release they were computed against" ], "effects": [ "Raises a change notice for jurisdictional rule changes with short lead time", "Triggers re-expansion of affected recurrence sets under the declared policy" ], "source_refs": [ "SRC-002", "SRC-010", "SRC-001", "SRC-015" ] }, { "id": "verify-release-integrity-and-freshness", "name": "Verify release integrity and freshness", "description": "Verify signature or checksum of each pinned reference dataset, confirm it is unexpired, and record an attestation.", "inputs": [ "release manifest", "publisher signatures or checksums", "current instant" ], "outputs": [ "per-dataset verification result", "expiry status", "freshness attestation record" ], "preconditions": [ "Publisher key material or checksum reference is available", "Each dataset entry declares an expiry or an explicit statement that none applies" ], "effects": [ "Emits a serial attestation and raises an alert when any dataset is expired or beyond the permitted adoption lag" ], "source_refs": [ "SRC-002", "SRC-016", "SRC-010" ] }, { "id": "project-to-interchange-format", "name": "Project temporal data to an interchange format", "description": "Render zone, recurrence, calendar and holiday content into a target interchange projection and report which semantics the projection cannot carry.", "inputs": [ "source model records", "target projection identifier", "truncation bounds" ], "outputs": [ "projected artifact", "loss report listing dropped fields and annotations", "validity upper bound where truncated" ], "preconditions": [ "Target projection is declared in the composition alignments", "Truncation bounds are stated when the target supports them" ], "effects": [ "Never silently drops binding mode, calendar key or provenance; unrepresentable semantics are reported", "Records the alias under which a zone was requested when it differs from the canonical identifier" ], "source_refs": [ "SRC-004", "SRC-007", "SRC-009", "SRC-010" ] }, { "id": "record-authority-decision", "name": "Record a civil time or holiday authority decision", "description": "Capture a legal instrument or proclamation that sets, changes or rescinds civil time arrangements or a public holiday, with announcement and effective instants recorded separately.", "inputs": [ "instrument identifier and citation", "competent authority", "territory or division references", "announcement instant", "effective instant", "decision content" ], "outputs": [ "authority decision record", "derived change notice", "mirroring task for reference data" ], "preconditions": [ "The issuing authority is competent for the stated territory", "Official publication reference is available or the gap is recorded" ], "effects": [ "Creates the authoritative record that the mirrored dataset is later reconciled against", "Starts the divergence clock when the mirrored dataset does not yet reflect the decision" ], "source_refs": [ "SRC-018", "SRC-020", "SRC-002", "SRC-019" ] } ], "composition": [ { "target": "Any model with temporal fields (universal mix-in surface)", "relation": "MIX-IN", "purpose": "Supplies the instant, interval, duration, granularity, recurrence and binding-mode value shapes so that sibling models express temporal facts once, consistently, with a declared binding rather than an implicit one.", "required": true, "source_refs": [ "SRC-017", "SRC-007", "SRC-009", "SRC-005" ] }, { "target": "world.place (jurisdiction and territory model)", "relation": "REFERENCE", "purpose": "Zones, week data, holidays and business centres are all scoped to jurisdictions and sub-jurisdictional divisions defined and maintained there; this model holds only references, never territory definitions or geometry.", "required": true, "source_refs": [ "SRC-019", "SRC-020", "SRC-012", "SRC-003" ] }, { "target": "world.identifierNaming (identifier and naming model)", "relation": "REFERENCE", "purpose": "tz identifiers, CLDR BCP47 timezone keys and calendar keys are governed schemes whose registration, canonicalisation and deprecation policy is held by the identifier model; this model records scheme membership, canonical form and alias relations.", "required": true, "source_refs": [ "SRC-011", "SRC-013", "SRC-002" ] }, { "target": "IANA Time Zone Database (tzdb)", "relation": "REFERENCE", "purpose": "Authoritative mirror of civil zone identifiers, offsets and transition history, consumed by pinned release identifier; treated as a record of civil decisions, not as the legal authority for them.", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "Unicode CLDR supplemental and BCP47 registries", "relation": "REFERENCE", "purpose": "Source of stable timezone keys, metazones, calendar keys, era tables, week data and territory calendar preference, pinned by CLDR release version alongside the zone data release.", "required": true, "source_refs": [ "SRC-011", "SRC-012", "SRC-013", "SRC-022" ] }, { "target": "IERS and BIPM leap-second and UTC publications", "relation": "REFERENCE", "purpose": "Authoritative, serial statements of leap-second decisions, cumulative TAI-UTC offsets and UTC realisation that the time-base bundle consumes and re-publishes with expiry.", "required": true, "source_refs": [ "SRC-014", "SRC-015", "SRC-016", "SRC-023" ] }, { "target": "RFC 3339 and RFC 9557 timestamp profile", "relation": "ALIGN", "purpose": "Declared alignment for instant serialisation, offset semantics and time zone or calendar annotation with criticality. Alignment only: conformance is claimed per interface after profile testing, not model-wide.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "RFC 5545 iCalendar and RFC 7529 non-Gregorian recurrence", "relation": "ALIGN", "purpose": "Declared alignment for zone observance structure, recurrence rule semantics, exceptions, and calendar-scaled expansion with skip behaviour.", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "target": "RFC 8984 JSCalendar", "relation": "ALIGN", "purpose": "Second, structurally independent alignment target that validates format-neutrality: the same semantics must project to both the iCalendar component form and the JSCalendar object form.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "RFC 9636 TZif", "relation": "ALIGN", "purpose": "Declared alignment for the binary zone projection, including local time type records, leap-second records and the leap-table expiration convention.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "RFC 7808 Time Zone Data Distribution Service", "relation": "ALIGN", "purpose": "Declared alignment for the distribution and versioning surface: version models, truncation with a validity bound, alias handling, expansion and change detection.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "W3C Time Ontology in OWL", "relation": "ALIGN", "purpose": "Declared alignment for the conceptual vocabulary of temporal entities, temporal reference systems via hasTRS, duration descriptions and Allen interval relations, giving the value shapes a published semantic anchor.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "FpML business day convention and business centre schemes", "relation": "ALIGN", "purpose": "Declared alignment for the date-adjustment enumeration and centre-addressed holiday calendars used by the working-day layer.", "required": false, "source_refs": [ "SRC-021" ] }, { "target": "Working-day calendar composition (internal)", "relation": "COMPOSE", "purpose": "The working-day calendar is not primitive: it is composed at build time from territory week data, one or more jurisdictional holiday sets and a centre combination rule, and must record every input release.", "required": true, "source_refs": [ "SRC-012", "SRC-019", "SRC-021" ] }, { "target": "Legacy N11 Time & Calendar Reference (world.timeCalendar 0.2.0)", "relation": "EXTEND", "purpose": "Supersedes the previous three-bundle description by separating value shapes from reference data, adding an explicit legal-authority layer, an anomaly-resolution layer and a governance bundle, and by demoting unsupported constructs such as named commercial contracts to out-of-model concerns.", "required": false, "source_refs": [ "SRC-002", "SRC-003", "SRC-018" ] }, { "target": "Records retention and statistics reference-period models", "relation": "REFERENCE", "purpose": "Those models embed this model's interval, recurrence and working-day shapes for retention triggers and reference periods; the meaning and legal force of the trigger or period remains theirs.", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must publish a temporal reference package that pins, at minimum, a zone data release identifier, a locale data release identifier, a leap-second table with its expiry, and a holiday feed snapshot per jurisdiction it serves.", "The package must contain the field binding declaration register, the timestamp conformance profile, the temporal precision profile and the disambiguation policy statement; a Dimension that consumes the mix-in without publishing these four artifacts is non-conformant.", "The package must nominate an accountable steward per fact class (time scale, zone, calendar, holiday, observance, working-day calendar) and a review cadence for each, with jurisdictional facts attributed to the declaring authority rather than to the steward.", "The package must retain superseded releases for the full retention period of any computation derived from them, so historical results remain reproducible.", "The package must declare its regional coverage explicitly and mark jurisdictions for which no authoritative holiday or civil-time source has been identified as gaps rather than as having no holidays." ], "namespace_guidance": "Use a stable model namespace such as world.timeCalendar with bundle-level sub-namespaces (timeBase, civilTimeZone, calendarSystem, temporalValue, recurrence, observance, referenceGovernance). Never mint local identifiers for concepts that already carry a governed identifier: reuse tz canonical identifiers, CLDR BCP47 timezone and calendar keys, official legal instrument citations and business centre codes verbatim, and namespace only the crosswalk entries, profiles, policies and Dimension-local overrides. Presentation names and zone abbreviations must never enter the identifier namespace.", "registry_links": [ "IANA Time Zone Database releases and the tz mailing list change record", "Unicode CLDR release index and the BCP47 calendar and timezone key registries", "IERS Bulletin C series and the IANA-distributed leap-seconds table", "National and supranational legal publication channels for civil-time instruments and holiday proclamations (for example EUR-Lex, the Federal Register and CFR, and national gazettes)", "Business centre code schemes used by the financial working-day calendars the Dimension serves" ] }, "canon_and_patch": { "canonicalization_rules": [ "Resolve every zone identifier to its canonical form before comparison or storage, retaining the alias actually supplied as separate provenance rather than overwriting it.", "Store instants as RFC 3339 date-time with an explicit numeric offset or Z; use -00:00 only to mean that the local offset is genuinely unknown, and never emit an unqualified local time across a boundary.", "Normalise deprecated calendar keys to their preferred replacement while retaining the supplied key in provenance.", "Serialise durations with a declared kind (exact or nominal) and a fixed unit order; do not silently normalise nominal months into days.", "Order transition series, leap records and era tables strictly by their start instant, and treat any out-of-order input as a validation failure requiring review.", "Record all timestamps in this model, including announcement, effective, observation, adoption, build and expiry instants, in RFC 3339 with seconds and an explicit offset or Z." ], "patch_rules": [ "Reference data is patched by adopting a new upstream release, never by hand-editing a mirrored value; a local divergence from upstream must be expressed as an explicit, owned, time-bounded override record with a documented reason and review date.", "Every patch records event time (when the change takes effect in the world) separately from observation time (when the Dimension learned of it) and adoption time (when it took effect in the Dimension).", "Corrections to historical values are additive: the prior value, the corrected value, the correcting instrument and the instant of correction are all retained, and derived outputs are either reissued or annotated according to the declared policy.", "A patch that changes a field's binding mode, a disambiguation policy, an adjustment convention or a granularity profile is breaking and requires a new profile version rather than an in-place edit.", "Patches arriving with short lead time from a jurisdictional decree follow an expedited path that still records the legal instrument before the mirrored data is changed." ], "compatibility_rules": [ "Adding a zone, calendar key, era, holiday or observance is compatible; removing, relinking or narrowing one is breaking for any consumer holding stored references.", "Changing the default calendar, default week data territory, default disambiguation choice or default adjustment convention is breaking, because it silently changes computed results.", "A projection may omit semantics it cannot express only if it emits a loss report; silent omission of binding mode, calendar key, criticality or provenance is a compatibility violation.", "Consumers must tolerate both monolithic and per-item versioning of upstream reference data and must not assume that an unchanged version identifier implies unchanged content without verifying integrity evidence.", "Claims of conformance to an external standard are made per interface, with test evidence recorded; the model itself claims alignment only." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the governing authority: legal instrument citations, IERS bulletin numbers, BIPM Circular T issue numbers, publisher release identifiers such as a tz database release.", "Governed global identifier or IRI: tz canonical zone identifiers, CLDR BCP47 timezone and calendar keys, ontology IRIs, business centre codes.", "UUID or ULID assigned by the adopting Dimension, used only for artifacts that no external authority identifies, such as crosswalks, profiles, policy statements, attestations and override records." ], "timestamp_rule": "All instants recorded by this model use RFC 3339 with seconds and an explicit offset or Z; event time, announcement time, effective time, observation or ingestion time, adoption time and expiry are recorded as separate fields and are never conflated. A date alone is never used as an identifier or as a version.", "serial_naming_rule": "Serial artifacts are named by issuing authority or Dimension, artifact class, and the issuer's own sequence number where one exists, with the issue instant recorded as a separate field rather than embedded as the identifier — for example an IERS bulletin is identified by its series and number, a working-day calendar projection by centre plus period plus build instant, and a freshness attestation by its monotonically increasing sequence number.", "integrity_rule": "Every ingested reference artifact records the integrity evidence it arrived with (publisher signature, checksum or entity tag) plus a locally computed content hash, the retrieval instant and the retrieving actor. Releases that should be signed but arrive unsigned are quarantined and adopted only under a recorded, time-bounded exception. Artifacts carrying an expiry are refused for computation after that instant." }, "policies": [ "Temporal reference data is treated as authority-derived: the legal instrument or authority publication is the record of truth and any mirrored dataset is evidence of it, so the two are reconciled and divergence is tracked rather than hidden.", "No temporal value is accepted or emitted without a declared binding mode; unqualified local times are rejected at every boundary.", "Every computed temporal result records the reference-data releases used, so that any past result can be reproduced exactly.", "Perishable data must not be used past its stated expiry; expiry breaches raise an operational alert rather than degrading silently.", "Known upstream inaccuracies, especially for pre-1970 and future timestamps, are propagated to consumers as explicit warnings and are never presented as settled fact.", "Where communities or authorities legitimately differ on an observance date, the model records the plurality with its determining bodies instead of forcing a single canonical value.", "Conformance to an external standard is asserted only with recorded test evidence; otherwise the relationship is recorded as an alignment.", "Time-scale names, tzdb identifiers and CLDR calendar types are open reference data by default, granted through the catalogue access model rather than informal scraping.", "Agents MUST NOT invent leap seconds, zone transitions or holidays; they may only ingest artefacts from the relevant authority and must mark completeness unknown when the artefact is missing.", "Redistribution of tzdb MUST preserve public-domain status, cryptographic signatures where present, and version stamps as required by BCP 175.", "Derived working-day calendars are not master data; they MUST cite the holiday instruments and weekend rule used and MUST NOT be presented as a global standard." ], "crud": { "read": [ "Reference data reads are open by default within the Dimension, subject to the catalogue's ownership and access controls and to redistribution terms attached to third-party datasets.", "Every read of a reference dataset resolves against a pinned release; reads that would resolve against an expired dataset fail closed.", "Reads of holiday and observance data return the confirmation status and the publication horizon alongside the values." ], "create": [ "New zones, calendars, eras, holidays and observances are created only from an identified authority publication or legal instrument, or as an explicitly owned Dimension-local override.", "Creation records the announcement instant, the effective instant and the observation instant separately, and cites the creating instrument.", "Dimension-local overrides require a named owner, a documented reason, a review date and an expiry." ], "update": [ "Reference values are updated by adopting a new upstream release or by recording a correction event; direct mutation of a mirrored value without a linked instrument or release is prohibited.", "Updates that change historical values trigger the declared recomputation or annotation policy for derived outputs and notify subscribers.", "Profile, policy and binding changes are versioned rather than edited in place." ], "delete": [ "Reference records are superseded, retired or rescinded rather than deleted; a rescinded holiday, a retired zone and a corrected transition all remain retrievable with their end instants and superseding references.", "Physical deletion is permitted only for genuinely erroneous local entries that were never published or relied upon, and requires an audited deletion record naming the approver.", "Retention of superseded releases is bounded by the longest retention obligation of any computation derived from them; expiry of that obligation is the only trigger for disposal." ] }, "roles": [ { "name": "Temporal reference data steward", "responsibilities": [ "Owns the release manifest and the pinning of zone, locale, leap and holiday datasets", "Runs change detection against upstream publishers and drives adoption within the declared lag", "Maintains the identifier crosswalk and the data quality caveat register" ] }, { "name": "Civil time and holiday authority liaison", "responsibilities": [ "Tracks legal instruments, proclamations and administrative decisions affecting civil time and holidays in covered jurisdictions", "Records announcement and effective instants and opens divergence records when mirrored data lags the instrument", "Escalates short-lead-time changes for expedited adoption" ] }, { "name": "Temporal semantics owner", "responsibilities": [ "Owns the field binding declaration register, the timestamp conformance profile, the temporal precision profile and the disambiguation policy statement", "Reviews new temporal fields in sibling models for correct binding and companion fields", "Approves breaking changes to defaults and profiles" ] }, { "name": "Calendar and observance curator", "responsibilities": [ "Maintains the adopted calendar registry extract, era tables and observance determination records", "Records determination method, determining community and confirmation status, including legitimate plural determinations", "Reconciles provisional observance dates when they are confirmed or corrected" ] }, { "name": "Interoperability and projection engineer", "responsibilities": [ "Maintains projections to binary zone, calendaring, JSON calendar and distribution-service formats", "Produces and reviews loss reports and cross-implementation recurrence test vectors", "Verifies round-trip fidelity before a projection is published" ] }, { "name": "Reference data assurance and audit", "responsibilities": [ "Verifies release signatures and checksums and issues freshness attestations", "Audits that computed results carry the release identifiers needed to reproduce them", "Reviews override records, exceptions and quarantined unsigned releases against their expiry" ] } ], "access": { "default_rule": "Temporal reference data is open for read within the Dimension by default because it describes public civil facts; write access is restricted to the named stewarding roles, and every read resolves against a pinned, unexpired release. Openness is a default for reference content only and is always granted formally through the catalogue's ownership and access models rather than assumed.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Third-party datasets carrying redistribution or licensing terms are restricted to the scopes those terms permit, and onward republication requires an explicit, audited grant.", "Embargoed authority decisions — announced to the Dimension before public publication — are restricted until the announcement instant recorded on the decision record.", "Dimension-local overrides that reveal internal operating arrangements, such as non-public cut-off times or internal business centres, are restricted to the owning function.", "Working-day calendar projections used for contractual or regulatory deadline computation are write-protected once published and may be corrected only through an audited reissue.", "Observance determination records that identify a specific religious community are treated as sensitive context and are released at the granularity needed, not by default at full detail.", "Unpublished draft tz patches and embargoed forthcoming proclamations are write-once steward-only until the authority publishes them.", "Commercial or scraped holiday feeds are not substitutes for gazettes and MUST NOT be loaded as master holiday records.", "High-resolution UT1-UTC series used for scientific work may be licensed separately from the civil leap-second table." ], "audit_requirements": [ "Every adoption of a new reference-data release records the actor, the instant, the previous and new release identifiers and the verification result.", "Every override, exception grant and quarantine of an unsigned release is logged with owner, reason, approver, review date and expiry.", "Every redistribution of third-party reference data is logged against the governing terms.", "Every correction to a historical temporal value logs the affected derived outputs and the reissue or annotation action taken.", "Freshness attestations are retained as an unbroken serial record so that any past computation can be shown to have used unexpired data.", "Every conversion or working-day answer MUST record tzdb version, leap-second bulletin identifier, calendar type and holiday-calendar version used, plus conversion time in RFC 3339.", "Redistribution events MUST be attributable to a redistributor role.", "Tombstones and supersessions remain visible to auditors." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Pinned reference data releases (zone data, locale data, leap table with expiry, holiday snapshots)", "Default binding mode, default calendar key, default week data territory and disambiguation policy", "Owner and steward contacts per fact class", "Known gaps, conflicts and regional coverage limits" ], "read_order": [ "AGENTS.md — identify the model, its type as a mix-in plus reference model, and the four URLs plus the pinned reference-data releases before any temporal computation", "Specification URL — read the scope statement, boundary notes and the bundle, layer and finding structure to establish what this model does and does not answer", "Storage type URL — learn the concrete projection in use (document store, files in version control, binary zone data, or a distribution service) and confirm it is a projection, not the semantics", "Interface URL — learn the read, create, update and supersede operations, the access scopes and the required release-pinning parameters", "Processes URL — learn change detection, adoption, override, correction, attestation and reissue procedures, including the expedited path for short-lead-time jurisdictional changes", "Field binding declaration register and conformance profiles — before writing or reading any temporal field, confirm its binding mode and required companion fields", "Data quality caveat register and coverage gaps — before presenting any historical or forward-dated result, confirm whether it falls in a declared unreliable range or an uncovered jurisdiction" ] } }, "coverage": { "claim": "Dual-provider research synthesis for a format-independent Time / Calendar mixin and governed reference model. It covers time scales, leap adjustment, civil time zones, calendar systems, temporal value shapes, recurrence, observances, working-day rules and reference-data governance. It does not claim exhaustive historical timezone or holiday coverage for every jurisdiction.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identity priority is applied concretely: legal instrument citations and publisher release identifiers first, then governed identifiers (tz canonical ids, CLDR BCP47 timezone and calendar keys, ontology IRIs, business centre codes), then Dimension UUIDs for crosswalks, profiles and attestations. The model explicitly forbids identifying zones by abbreviation, offset or country code, and forbids dates as identifiers." }, { "dimension": "lifecycle", "status": "covered", "notes": "Covered at three levels: the authority decision lifecycle (announcement, effect, rescission) in the zone-legal-authority and public-holiday layers; the reference-data release lifecycle (release, verify, adopt, expire, supersede) in the governance bundle; and the derived-artifact lifecycle (expansion, reissue, freeze) in recurrence and working-day layers." }, { "dimension": "relationships", "status": "covered", "notes": "Zone-to-scale, transition-to-zone, era-to-calendar, observance-to-calendar, holiday-to-instrument, recurrence-to-calendar-scale, and working-day-calendar-to-inputs are all modelled, plus Allen interval relations from the W3C ontology for interval ordering. Cross-model links are expressed as sixteen composition entries." }, { "dimension": "temporal", "status": "covered", "notes": "Event, announcement, effective, observation, adoption, build and expiry instants are separated by rule; RFC 3339 with seconds and explicit offset or Z is mandated; granularity is declared rather than inferred; open and unbounded endpoints are distinguished from missing values." }, { "dimension": "provenance", "status": "covered", "notes": "Every fact carries an evidence class and cites either a legal instrument, an authority publication, a mirrored release or a reconstruction. The provenance chain from instrument through mirrored dataset to local record is an explicit question, and upstream accuracy caveats are propagated rather than absorbed." }, { "dimension": "ownership", "status": "covered", "notes": "Six roles are defined with distinct responsibilities; jurisdictional facts are attributed to the declaring authority while the steward owns only the mirroring. Accountability per fact class is a required data element and an AGENTS.md field." }, { "dimension": "validation", "status": "covered", "notes": "A validation function checks values against the binding, timestamp and precision profiles; ordering violations in transition, leap and era series fail validation; cross-implementation recurrence test vectors and round-trip projection tests are required; orphaned recurrence overrides are detected." }, { "dimension": "access", "status": "covered", "notes": "Default is open read for reference content with formal grant, restricted write to stewarding roles, with five named exception classes (redistribution terms, embargoed decisions, internal overrides, published deadline calendars, community-identifying observance records) and five audit requirements. Scopes cover bundle, layer, finding and artifact." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Supersession rather than deletion is the rule; rescinded holidays, retired zones and corrected transitions remain retrievable with end instants. Retention of superseded releases is bound to the longest retention obligation of any derived computation, which is the only disposal trigger; physical deletion requires an audited approval record." }, { "dimension": "interoperability", "status": "covered", "notes": "Four structurally independent projections are aligned (binary zone format, iCalendar components, JSCalendar objects, distribution-service resources) plus an ontology alignment, with a mandatory loss report and a prohibition on silently dropping binding mode, calendar key, criticality or provenance. Conformance is claimed only per interface with test evidence." }, { "dimension": "calendar systems", "status": "covered", "notes": "Registered calendar keys, astronomical class, determination method, intercalation and leap months, eras with proleptic boundaries and inheritance, and territory calendar preference are modelled, using the registry that recurrence and timestamp standards reference normatively." }, { "dimension": "recurrence", "status": "covered", "notes": "Rule structure, filter evaluation order, anchoring, bounds, week start, exceptions, per-occurrence overrides and identity, calendar-scaled expansion and skip behaviour are each separately answerable, with expansion-window and re-expansion policy made explicit." }, { "dimension": "authority and legal basis", "status": "covered", "notes": "A dedicated layer distinguishes the legal instrument from its database mirror, backed by a supranational directive, a national regulation with a petition process, and the maintenance procedure that explicitly disclaims policy-setting authority." }, { "dimension": "precision and uncertainty", "status": "gap", "notes": "Declared granularity, all-day semantics, bounded ranges and open endpoints are covered from accessible primary sources, but the richer qualified-date vocabulary of ISO 8601-2 and EDTF (uncertain and approximate qualifiers, unspecified digits, one-of sets) could not be grounded because both the ISO catalogue and the Library of Congress specification pages returned access errors during research. Treated as a gap, not presented as canonical." }, { "dimension": "measurement", "status": "covered", "notes": "Exact versus nominal duration arithmetic, counting basis, cut-off times, endpoint inclusivity, inter-scale offsets and elapsed-time computation across transitions and short months are modelled explicitly." }, { "dimension": "security", "status": "covered", "notes": "Release signing and checksum verification, integrity evidence retention, quarantine of unsigned releases and serial freshness attestation are required, matching the upstream expectation that releases should be cryptographically signed." }, { "dimension": "privacy", "status": "not-applicable", "notes": "The model holds public civil reference data and contains no personal data by design. The single sensitivity is that observance determination records can identify a religious community, which is handled as an access exception rather than as a privacy regime; personal temporal data belongs to the host record in the sibling model that embeds these shapes." } ], "known_omissions": [ "ISO 8601-1:2019 and ISO 8601-2:2019 are the underlying international standards but could not be fetched (ISO returned 403 and the Library of Congress EDTF pages returned 403), so they are represented indirectly through the IETF profile, the W3C granularity note and the calendaring standards; the uncertain, approximate and set-valued date vocabulary is therefore recorded as a gap.", "No global authoritative registry of public holidays exists. Coverage is demonstrated with one national feed and two legal instruments; jurisdictions without an identified authoritative source must be marked as gaps, and the model deliberately does not endorse aggregated secondary holiday datasets.", "Sighting-based observance determination (notably Hijri months determined by local observation) cannot be predicted; the model records method, community and confirmation status but supplies no computation, and per-community authority sources were not individually verified.", "Leap smearing is named as a policy option but no smear algorithm is specified, because the widely used smear windows are vendor practice rather than standardised.", "The specific rule of the CIPM proposal for the new UT1-UTC maximum, due for approval at the 28th CGPM in 2026, is not yet available and is therefore modelled as a pending lifecycle event rather than as a value.", "Business centre code lists were referenced by scheme rather than enumerated; the individual centre scheme file was not retrieved successfully during research.", "Historical calendar reform events (for example Julian-to-Gregorian adoption dates, which differ by jurisdiction by up to several centuries) are within scope conceptually but no per-jurisdiction adoption dataset was grounded in a primary source here.", "CalConnect's general recurrence representation was identified as a relevant standard but its document could not be retrieved (404), so no structure depends on it.", "ISO 8601-1:2019 and ISO 8601-2:2019 full texts were not retrieved (paywalled); alignment is via RFC 3339 and RFC 9557 citations only.", "ISO 19108:2002 temporal schema was cited by OWL-Time but not independently read.", "RFC 9636 TZif, RFC 7808 TZDIST, RFC 8984 JSCalendar and RFC 5905 NTP were identified as related and not fully retrieved.", "GNSS timescales (GPS, GLONASS, Galileo, BeiDou) and operator leap smearing lack a primary source in this pass.", "No global primary holiday, weekend or financial business-day register was found; national gazettes remain masters.", "Windows timezone IDs and CLDR windowsZones mapping were not fetched as a first-party artefact.", "Astronomical new-moon algorithms, Hebrew postponement tables and Umm al-Qura internals are tradition-specific authorities not copied here.", "Negative leap seconds are allowed by the IERS framework but have never been issued; encoding remains a rare lifecycle case." ], "conflicts": [ "The tz database and CLDR deliberately diverge on identifier stability: tz relinks and renames zones as the ground truth changes, while CLDR preserves canonical identifiers to avoid churn. Consumers must choose a persistence layer; the model requires the choice to be declared rather than resolving it.", "RFC 3339 originally treated Z as implying UTC is the preferred reference point; RFC 9557 updates that reading so Z means the local offset is unknown. Systems built to either reading will disagree about the same string, so the model records the interpretation in the conformance profile.", "The tz database records leap-second-aware behaviour as optional because POSIX requires leap seconds to be excluded from the time count; the same instant therefore has different representations across POSIX and leap-aware systems.", "Legal instruments and their database mirror can diverge for weeks after a decree, and the mirror maintainer explicitly aims at what the average person on the street would think the time is rather than at the statute. The model tracks divergence rather than assuming agreement.", "Hijri calendar variants in the calendar registry (tabular civil, tabular astronomical, Umm al-Qura, Saudi sighting) yield different dates for the same nominal day; there is no single correct value, only a declared method.", "The pinned leap-second table and the CGPM decision to raise the UT1-UTC tolerance by 2035 point in different directions for long-horizon planning: current data assumes the existing regime while the governing decision has already changed it.", "The FpML NEAREST convention is defined by reference to Sundays and Mondays, which does not generalise to territories whose weekend is not Saturday and Sunday; applying it outside that assumption is undefined.", "RFC 3339 treats Z and +00:00 as implying UTC is the preferred reference point; RFC 9557 updates Z so that implication no longer holds. Both keep -00:00 for unknown local offset.", "ISO 8601 mandates leap seconds in lexical forms; OWL-Time notes XML Schema/XSD lexical forms ignore them. RFC 5545 allows second 60 but says non-supporting implementations SHOULD treat it as 59, and durations MUST NOT consider leap seconds. POSIX/Unix time also omits leap seconds.", "RFC 9557 IANA timezone names mean rules current at interpretation time; RFC 5545 VTIMEZONE is a snapshot embedded in one object. Offset timezones such as +01:00 are legal in IXDTF but strongly discouraged.", "RFC 5545 CALSCALE exists but RFC 7529 states it has never been used; non-Gregorian recurrence requires RSCALE.", "tzdb is complete by design only for post-1970 civil clocks of recorded locations; using it as a universal historical atlas overclaims.", "CGPM Resolution 4 will change the UT1-UTC bound in or before 2035; current IERS plus-or-minus 0.9 second practice remains in force until then. Do not claim the leap second has already ended.", "ILO C132 is about paid annual leave, not a holiday calendar standard; using it as a date register would be a category error." ], "regional_assumptions": [ "The worked holiday example is United Kingdom bank holidays with three divisions and a ten-year rolling horizon; other jurisdictions publish on different horizons, at different granularity and with different substitution rules.", "The daylight saving rule cited as a legal instrument is the European Union arrangement (last Sunday in March to last Sunday in October at 01:00 GMT); it is in force but has been the subject of repeated repeal proposals, and it does not bind non-EU states.", "The administrative zone-boundary example is United States federal regulation, where boundaries are described by county and municipal lines and changed by petition and rulemaking; many jurisdictions use entirely different mechanisms.", "Territory week data assumes CLDR's territory-scoped defaults, which are defaults rather than legal facts and can be overridden by sector practice within the same territory.", "Weekend definitions are assumed to be territory-scoped day sets; territories with half-day weekends or sector-specific rest days are representable but not exercised in this model.", "Business day conventions are drawn from a financial-industry scheme reflecting Western settlement practice and may not match statutory deadline rules in civil-law jurisdictions.", "Observance coverage is illustrative and not exhaustive for any tradition; the registry-backed calendar variants are the only observance facts grounded in a primary source here.", "Internet civil timestamps default to the Gregorian calendar as profiled by RFC 3339, not as a claim that all jurisdictions use Gregorian for domestic law.", "Saturday-Sunday weekends are a common but non-universal default and must not be inferred from tzid alone.", "English AREA/LOCATION tzids are the interchange identifiers; localised labels come from CLDR.", "Holiday and in-lieu law is sub-national in several federations; a country-level calendar can be incomplete.", "DST remains politically unstable, as illustrated by tzdb 2026c (Alberta permanent -06 from 2026-06-18; Morocco permanent +00 from 2026-09-20)." ], "adversarial_checks": [ "Counterexample sought for zone identifiers as stable keys: the tz maintainers state that names, boundaries, offsets and abbreviations are not all part of the stable interface and that backward links exist, while CLDR maintains a separate stable layer. The claim that a tzid is a durable primary key is therefore rejected, and a crosswalk with a declared persistence layer is required instead.", "Counterexample sought for treating the tz database as authoritative: RFC 6557 states the coordinator shall not set time zone policy and works from consensus on the ground, and 49 CFR Part 71 shows boundaries set by a different body under statute. A separate legal-authority layer was added rather than collapsing law into the mirror.", "Counterexample sought for UTC as a fixed scale: BIPM Circular T is a monthly numbered publication, IERS issues serial leap decisions, the leap table carries a hard expiry, and CGPM has resolved to change the UT1-UTC tolerance by 2035. UTC is therefore modelled as versioned, perishable, governed data rather than as a constant.", "Counterexample sought for a single canonical date per observance: the calendar registry itself carries four Hijri variants differing only in determination method. A single canonical observance date was rejected in favour of method, community and confirmation status.", "Counterexample sought for the previous version's contract and projection constructs: no primary source supports named commercial constructs such as a subscription contract or a redistribution contract as part of a temporal meta-model. These were rejected as domain artifacts of a particular business model and replaced by evidence-backed governance concerns (release pinning, integrity, expiry, redistribution as an access exception).", "Counterexample sought for treating recurrence as calendar-neutral: RFC 7529 shows that recurrence expansion is calendar-scale dependent and needs explicit skip and leap-month handling, so a scale-aware recurrence layer was made mandatory rather than optional.", "Counterexample sought for JSON, YAML or a database being the model: the same semantics are shown to project into a binary zone format, an iCalendar component, a JSON calendar object and a distribution-service resource, which confirms storage-neutrality and forced the loss-report requirement.", "Counterexample sought for 'floating time is just local time': iCalendar and JSCalendar both define floating values that intentionally have no fixed instant, so a three-way binding contract was required in place of a two-way local-versus-UTC split.", "Falsifiability check on the coverage claim itself: the precision-and-uncertainty dimension is recorded as a gap because the relevant ISO and Library of Congress sources returned access errors, rather than being asserted from memory.", "Local 02:30 on a spring-forward day may be nonexistent; local 01:30 on a fall-back day may be ambiguous. Resolution policy must be explicit or the convert function must fail closed.", "A timestamp of 2016-12-31T23:59:60Z is a valid positive leap second; rejecting it or treating it as 2017-01-01T00:00:00Z without a stated policy is an interoperability defect.", "2020-01-01T00:00:00+01:00[Europe/Paris] and 2020-01-01T00:00:00+01:00[+01:00] are not equivalent for 'six months later' arithmetic.", "UNTIL on an RRULE in UTC combined with DTSTART in America/New_York can drop or duplicate the last occurrence if the consumer ignores RFC 5545 UTC UNTIL rules.", "A yearly Islamic holiday expanded on Gregorian anniversary, or with the wrong islamic-* CLDR variant, will be the wrong civil date.", "Asia/Calcutta must resolve as a link to Asia/Kolkata, not as a second zone.", "A missing sub-national holiday must yield completeness=unknown, not working-day=true.", "tzdb 2026c Morocco +00 from 2026-09-20 will disagree with a converter pinned to an earlier release; version skew must be detected as RFC 9557 inconsistency, not silently corrected.", "Second instance of a civil day under a date-line move (America/Juneau 1867) must not collapse to a single Gregorian date without recording both labels.", "Claiming conformance to ISO 8601-1:2019 without the ISO text, or claiming leap seconds have already been abolished before the CGPM implementation, is a false completeness claim." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both independent providers treat temporal value shapes as reusable context embedded by other models and civil-time/calendar datasets as governed reference data. Clock synchronization, event participation, jurisdiction geometry, labour entitlement and domain deadline policy remain separate models." }, "decisions": [ { "concept": "Seven-bundle logical structure", "disposition": "accepted-from-claude-validated-by-grok", "rationale": "Grok independently covers the same time-base, zone, calendar, recurrence and observance semantics in three broader bundles. The Claude hierarchy preserves the useful boundaries among civil zones, temporal value shapes, recurrence, observance and reference-data governance without duplicating Grok nodes." }, { "concept": "Time / Calendar is a mixin plus governed reference data", "disposition": "accepted-from-both", "rationale": "Temporal values are embedded by host models, while time scales, zone transitions, calendar rules and public-holiday proclamations have their own authorities, versions and lifecycle." }, { "concept": "Timestamp as artifact identifier", "disposition": "rejected", "rationale": "Artifact identity follows the authoritative master-system identifier and otherwise UUIDv7 or ULID. RFC 3339 timestamps with seconds and an explicit offset or Z are separate created/changed/event facts, never the sole identifier." }, { "concept": "IANA timezone identifier is an eternal object key", "disposition": "rejected", "rationale": "tzdb links, canonical names, political rule changes and CLDR stability mappings require version pinning, alias history and a declared persistence layer." }, { "concept": "The timezone database is the legal authority", "disposition": "rejected", "rationale": "Civil-time policy is set by competent jurisdictions; tzdb mirrors observed consensus and must preserve the legal instrument, mirror lag and conflict separately." }, { "concept": "UTC and leap-second tables are timeless constants", "disposition": "rejected", "rationale": "Leap decisions, tables, expirations and the planned change to the UT1-UTC regime are versioned governed facts with freshness obligations." }, { "concept": "Floating, offset and named-zone times are equivalent", "disposition": "rejected", "rationale": "They have different resolution semantics; gaps, overlaps and offset-versus-zone conflicts require an explicit policy or fail-closed result." }, { "concept": "Recurrence is Gregorian and timezone neutral", "disposition": "rejected", "rationale": "RSCALE, skip behavior, calendar variants, zone transitions, exceptions and per-occurrence overrides materially change expansion." }, { "concept": "Public holidays and weekends have one global master", "disposition": "rejected", "rationale": "The competent jurisdiction or recognized community is the master; aggregators are mirrors and missing sub-national coverage must remain unknown rather than inferred as a working day." }, { "concept": "Format alignment implies universal conformance", "disposition": "rejected", "rationale": "RFC 3339/9557, iCalendar, JSCalendar, TZif, tzdb, CLDR and OWL-Time are version-pinned projections or alignments with explicit loss reports and conflicting assumptions." } ], "publicationHolds": [ "Verify live availability, editions and claim-level support for every accepted primary source, including current tzdb, BIPM/IERS, IETF and Unicode releases.", "Complete jurisdictional profiles for holiday and working-day authorities and direct clause-level verification of paywalled ISO 8601-1/2 before promoting a universal completeness claim." ], "deferredResearch": [ "Qualified uncertain and approximate dates, unspecified digits and set-valued dates from ISO 8601-2 and EDTF.", "GNSS time scales, clock synchronization and time-transfer traceability profiles.", "Jurisdiction-by-jurisdiction calendar reform, historical timezone and public-holiday authority datasets.", "Sighting-based religious calendar confirmation, community authority and post-publication correction workflows.", "Vendor leap-smear algorithms, exchange-specific trading calendars and sector-specific business-day conventions." ] }, "statistics": { "sources": 31, "bundles": 7, "layers": 20, "findings": 20, "questions": 111, "artifacts": 27, "functions": 13 } }