TIMEVERSE
Syncing T2°...
Timeverse
Docs

SWT/Space Layer

Simplified World Time (12 zones), Tiles, and Long-Cycle Calendar (T_cyclezero)

Status: Official Spec
DOI: 10.5281/zenodo.XXXXXXX

Abstract

This document specifies the Timeverse Space Layer, defining: (i) SWT (Simplified World Time) as a 12-zone public context label suitable for human interfaces (HTIL/T-Watch/Tilemedia), routing domains, and audit scoping; (ii) Tiles as deterministic identifiers for community feeds, moderation scope, routing, and provenance organization; and (iii) a D-Calendar projection using a long-cycle period 𝑇cyclezero (Earth-first profile) for human-friendly calendar decomposition. SWT/Tiles/D-Calendar/capsuletime/compass fields are public context and MUST NOT change tick-canonical execution semantics. Canonical execution remains governed by convention_id and tick fields as defined by the Phase-Coordination Conventions.

Normative dependencies (DOIs)

Related (informative)

1. Scope and non-goals

Principle 1.1 (Space Layer is context, not execution): SWT zones, tile identifiers, D-Calendar fields, capsuletime strings, and compass labels are context/UI. They MAY be used for routing, community scoping, moderation, audit organization, and human comprehension. They MUST NOT modify canonical execution semantics (cycle anchoring, ticks, window membership) which remain defined by convention_idand tick-canonical fields (per Conventions).

Principle 1.2 (Context is not secret): SWT/tile/calendar/capsuletime/compass fields are public context and MUST NOT be treated as secrets. Security is provided by signatures, nonces, anti-replay policy, and canonical encoding selected by security_profile_id(as specified by the Security Profile).

Remark 1.1 (Conventions precedence): When this document references arithmetic time, modulo, or derived phase concepts, the normative meaning is defined by Conventions. This Space Layer does not redefine execution semantics.

2. SWT: Simplified World Time (12 zones)

Definition 2.1 (SWT zone identifier):

Under swt_schema_id=TV-SWT-12Z-2025-12, an SWT zone is an integer:

swt_zone ∈ {1,2,...,12}

Definition 2.2 (Informative UTC-offset set label):

SWT zones MAY be presented as a simplified set of two integer UTC offsets:

offsets(z) := {2z-13, 2z-12} hours, z∈{1,...,12}

Example: SWT1 corresponds to {-11,-10}, SWT12 corresponds to {+11,+12}. This set is a display label and MUST NOT define protocol arithmetic.

Remark 2.1 (Geographic SWT mapping is deployment policy): Deployments MAY map SWT zones to geography (e.g. 30-degree longitude bands) for UI/routing/audit. If an automatic mapping from coordinates (GPS/planetary) is used, the mapping policy MUST be specified explicitly and frozen under swt_schema_id. Such mapping is out of scope here and MUST NOT alter tick-canonical execution fields.

Remark 2.2 (Temporal SWT projection is UI-only): Deployments MAY also use SWT as a UI projection aligned with a local “HS hour” display (e.g. “SWT-k shows HS k:00:00”). This is UI-only: it MUST NOT change convention_id, cycle_index, phi_ticks, or any verification rule.

3. Tiles: deterministic identifiers (600 tiles)

Principle 3.1 (Tiles are protocol identifiers): Tiles are identifiers used for routing/community/audit scope. They are not physical objects. If tiles are used for policy enforcement, parsing and edge handling MUST be deterministic.

3.1 Tile domains and numbering

Definition 3.1 (Tile domains):

Under tile_schema_id=TV-TILE-SWT12x25x2-2025-12:

swt_zone ∈ {1,...,12}, tile_row ∈ {1,...,25}, tile_col ∈ {1,2}

Each SWT zone contains a deterministic 25×2 tile layout (25 rows, 2 columns), totaling 50 tiles per SWT and 600 tiles overall.

Definition 3.2 (Local and global tile indices):

Define the local tile index within a given SWT zone:

tile_local(r,c) := 2(r-1)+c ∈ {1,...,50}, r∈{1,...,25}, c∈{1,2}

Define the global tile index:

tile_global(z,r,c) := 50(z-1) + tile_local(r,c) = 50(z-1)+2(r-1)+c ∈ {1,...,600}

where z=swt_zone.

Principle 3.2 (Deterministic ordering):

The numbering order is:

  • within an SWT zone: top to bottom (increasing tile_row),
  • within a row: left to right (tile_col=1 then 2),
  • across SWT zones: left to right from SWT1 (leftmost) to SWT12 (rightmost).

3.2 Canonical tile identifier string

Definition 3.3 (Canonical tile identifier string):

A canonical tile identifier string is:

tile_id := "swt="swt_zone";tile="tile_global

The string MUST be ASCII, MUST contain no whitespace, MUST use lowercase keys exactly as shown, and MUST encode integers in base-10 with no leading zeros (except the integer 0, which does not occur here).

Principle 3.3 (Tile internal consistency): If an encoding carries both swt_zone and tile_global (and/or tile_local), implementations MUST verify consistency with the mapping above. Inconsistent encodings MUST be rejected.

3.3 Required “listing” shape (two columns of 25 per SWT)

Remark 3.1 (SWT1 listing: 25 rows × 2 columns): SWT1 corresponds to the following tile pairs (row-major), which match the required UI listing:


  1   2
  3   4
  5   6
...
 47  48
 49  50

Remark 3.2 (SWT12 listing: starts at 551): SWT12 starts at (551, 552), then (553, 554), and so on, ending at (599, 600).

Remark 3.3 (Global map excerpt: first two rows, SWT1 (left) to SWT12 (right)): Row 1 across zones:

SWT1:  1  2 | SWT2: 51 52 | ... | SWT12: 551 552
Row 2 across zones:
SWT1:  3  4 | SWT2: 53 54 | ... | SWT12: 553 554
This excerpt is sufficient to reconstruct the full 25-row map deterministically via the formulas above.

4. D-Calendar: long-cycle projection with Tcyclezero

Definition 4.1 (Calendar schema and constants):

Under calendar_schema_id=TV-DCAL-30y-12m-5w-6d-2025-12, the calendar projection uses an Earth-first day length:

Tday := 86400 s (Earth-first day length, informative default),

and defines a long cycle (“cyclezero”):

Tcyclezero := 30·12·5·6·Tday = 933,120,000 s.

This long cycle is a calendar projection period and MUST NOT be confused with the execution cycle period 𝑇cycle used for phase-window coordination (defined by convention_id under Conventions).

Remark 4.1 (Earth-first calendar projection): In this schema, one dYear is defined as 360 Earth-first days (12 months of 30 days). This is a calendar projection and is not a claim about astronomical years.

Definition 4.2 (Negative-safe modulo):

All modulo operations in this document MUST use the negative-safe modulo convention defined in Conventions.

Principle 4.1 (Calendar projection uses the same arithmetic time variable): The D-Calendar projection MUST be computed from the same arithmetic time variable used by the deployment under convention_id (per Conventions). UTC/RFC3339 may be used for display only.

Definition 4.3 (Calendar epoch):

The D-Calendar projection uses a calendar epoch 𝑡epoch. By default, deployments SHOULD set 𝑡epoch := 𝑡0 of the active convention_id (per Conventions), unless a different epoch is explicitly declared and shared as part of deployment UI policy.

Remark 4.2 (Calendar epoch interoperability): Unless 𝑡epoch is explicitly specified and shared, D-Calendar fields are UI-only displays and are not interoperable identifiers.

Definition 4.4 (D-Calendar decomposition (derived)):

Let 𝑡 be the deployment arithmetic time variable (seconds or fixed-point) and let 𝑡epoch be the calendar epoch. Define elapsed calendar seconds:

Δ𝑡 := 𝑡 - 𝑡epoch

Define:

day_index := ⌊Δ𝑡/Tday⌋ ∈ ℤ,

cyclezero_index := ⌊Δ𝑡/Tcyclezero⌋ ∈ ℤ.

Within a cyclezero, define:

day_in_cyclezero := (day_index mod 10800) ∈ {0,...,10799}.

Then define the D-Calendar fields:

  • dYear ∈ {1,...,30}: years per cyclezero,
  • dMonth ∈ {1,...,12}: months per year,
  • dWeek ∈ {1,...,5}: weeks per month,
  • day ∈ {1,...,6}: days per week.

A deterministic mapping is:

dYear := ⌊day_in_cyclezero/360⌋+1,

dMonth := ⌊(day_in_cyclezero mod 360)/30⌋+1,

dWeek := ⌊(day_in_cyclezero mod 30)/6⌋+1,

day := (day_in_cyclezero mod 6)+1.

Remark 4.3: All D-Calendar fields are derived/UI-only unless explicitly included in signed policy objects under a suite-defined registry. If signed, canonical encoding and policy rules are defined by the Security Profile.

5. Capsuletime and compass labels (UI-only)

Definition 5.1 (Capsuletime (display string)):

Under capsuletime_schema_id=TV-CAPSULETIME-2025-12, a capsuletime string MAY be produced for human sharing (QR, logs). A recommended format is:

capsuletime := planet.elapsedDays.SWTz.tileGlobal.cyclezero.dYear.dMonth.dWeek.day@HS:Binute:Second.Microseconds.Angle.

All components are derived from the arithmetic time variable and UI policies. Capsuletime MUST be treated as UI-only and MUST NOT drive verification.

Remark 5.1 (Compass labels are UI projections): Compass labels (e.g. dEAST, dSOUTH) and angles are UI projections intended for HTIL/T-Watch comprehension and MUST NOT affect execution semantics. If used, the mapping from displayed HS/Binute/Second to an angle MUST be specified by UI policy (not by execution policy).

Remark 5.2 (Do not use capsuletime as a secret): Capsuletime and all Space Layer fields are public context. They MAY be bound as associated data (AAD) under the Security Profile, but MUST NOT be treated as cryptographic secrets.

6. Interoperability with Q-Address / TAQA / TSAE (informative)

Remark 6.1 (How to carry SWT/Tiles in execution stacks): Execution remains tick-canonical (Conventions/Q-Address/TAQA). SWT and tile identifiers may be carried as:

  • UI-only metadata: in ext_ui (recommended for display),
  • Signed policy scope: in ext_signed only if a registry-defined schema is used,
  • Scope namespace: embedded into scope strings if deployments standardize scope canonicalization.

Remark 6.2 (Recommended minimum: keep execution canonical): When used with TAQA/Q-Address, the executable object MUST remain anchored to convention_id, cycle_index, and tick-canonical window fields. SWT/Tiles/Capsuletime/Compass should remain informational metadata.

7. Multiplanetary framework (informative)

Remark 7.1 (Planet identifiers): Deployments MAY use a planet_id (e.g. earth, mars, titan) in capsuletime and UI displays. If different day lengths are used for D-Calendar-like projections on other bodies, the projection constants MUST be explicitly declared under a distinct calendar_schema_id and MUST NOT change tick-canonical execution semantics.

8. Conclusion

This Space Layer defines SWT12 zones, a deterministic 600-tile schema (25×2 per SWT, ordered top-to-bottom and SWT1-to-SWT12 left-to-right), and a long-cycle D-Calendar projection using 𝑇cyclezero. These constructs support human interfaces (HTIL/T-Watch/Tilemedia), community and routing domains, and audit scoping. They are public context and do not modify tick-canonical execution semantics, which remain governed by convention_id and the Phase-Coordination Conventions, with security provided by versioned Security Profiles.

References