共同時間座標層與異質時空間轉換

從 Unix Epoch、物理授時、時間尺度到主體性 AI 生命史對齊的理論命題

作者：Neo.K
版本：v0.1 / 理論論文草稿
定位：內部理論論文／可後續改寫為公開發表版
狀態：命題性、工程可實作、部分數學形式待深化

摘要

本文提出「共同時間座標層」（Common Temporal Coordinate Layer, CTCL）命題：對於人類、計算機、Agent、模擬器、數位孿生、機器人、分散式系統與未來主體性 AI 而言，一個真正可互操作的時間基礎設施，不應僅回傳「現在幾點」或單一 Unix timestamp，而應提供一個可追溯、可轉換、可版本化、可映射至異質時間系統的共同參考瞬間。

傳統計算機時間常以 Unix Epoch 為核心，將某一參考起點之後的經過時間編碼為整數或高精度數值。此方法在工程上極具價值，但容易造成概念混淆：時間編碼不等於物理時間本體；UTC、TAI、UT1、GPS Time、POSIX time、NTP time、地方民用時間與自定義模擬時間也不是同一層級的對象。若未來大量 Agent 與持續存在的智慧體需要跨平台、跨國家、跨模擬環境、跨具身系統甚至跨生命史交換事件，則僅共享 Unix timestamp 仍不足以保證語義一致。

本文因此將時間基礎設施拆分為五層：物理授時來源、參考時間尺度、Epoch 編碼、系統時間轉換與局部表示。進一步地，本文將任意時間系統表示為：

\mathcal S_i = (E_i,\tau_i,r_i,\phi_i,\Pi_i,\Omega_i)

其中：

$E_i$ ：Epoch 或原點；
$\tau_i$ ：系統內部時間座標；
$r_i$ ：相對速率；
$\phi_i$ ：相位偏移；
$\Pi_i$ ：時間政策與跳秒／離散規則；
$\Omega_i$ ：來源、版本與不確定度資訊。

不同系統之間透過轉換算子：

\Phi_{i\rightarrow j}

進行映射。若存在共同參考瞬間 $I^\*$ ，則各系統時間可寫為：

\tau_i=\Phi_i(I^\*)

本文主張，這一結構不僅可用於時區、曆法與 Epoch 轉換，也可進一步處理遊戲世界時間、加速模擬、暫停／恢復系統、事件時間、機器人任務時間、數位孿生時間，以及未來主體性 AI 的持續記憶與生命史對齊。

本文最終提出：共同時間不是單一數字，而是「共同參考瞬間＋時間尺度語義＋來源追溯＋轉換圖」的組合。 若未來智慧體需要跨系統共同存在，則時間 API 可能從便利工具上升為文明級機器協議的一部分。

關鍵詞： Unix Time、POSIX Time、UTC、TAI、時間尺度、Epoch、共同參考瞬間、時間轉換圖、Agent、主體性 AI、生命史、嵌套時間、時空間耦合

0. 作者聲明：本文不是「世界時鐘網站」設計稿

本文表面問題很簡單：

能否建立一個網頁與 API，讓任何存在調用後，獲得共同時間？

如果只停留在工程直覺，答案似乎極度普通：

讀取系統時間；
回傳 Unix timestamp；
附加 UTC；
完成。

然而本文認為，真正問題不是「如何取得現在時間」，而是：

不同存在如何確認自己所引用的是同一個瞬間，以及此瞬間如何被映射到不同時間系統？

這一問題至少涉及：

物理授時來源；
參考時間尺度；
Epoch；
編碼方式；
時區；
曆法；
跳秒政策；
版本；
不確定度；
局部系統時間；
模擬時間；
事件時間；
持續智慧體生命史。

因此本文的目標不是設計一個「漂亮的時鐘頁面」，而是建立一個更一般的理論命題：

異質時間系統需要共同參考層。

1. Unix Time 的價值與限制

Unix time 的工程價值來自極簡性。

令某一 Epoch 為：

E_U

則時間值可表示為：

u(t)=\Delta(E_U,t)

其中 $\Delta$ 表示從 Epoch 到事件 $t$ 的編碼距離。

這種表示有數個巨大優勢：

易儲存；
易比較；
易排序；
易傳輸；
易做差；
易跨程式語言；
易作資料庫索引。

但問題在於：

\text{Unix timestamp} \neq \text{Time itself}

更準確地說：

u(t)

是一種工程編碼。

它不是：

原子時間本體；
地球自轉；
UTC 的完整語義；
地方民用時間；
GPS Time；
NTP Time；
任意物理參考系的固有時。

因此，若一個 API 只回傳：

{
  "time": 1783420000
}

它其實省略了大量問題：

這是哪一種編碼？
單位是秒、毫秒、微秒還是奈秒？
是否允許小數？
是否採用 POSIX 語義？
如何處理 leap second？
來源是本機 clock、NTP、GNSS 或其他？
此值何時觀測？
是否同步？
不確定度多少？

在低風險應用中，這些問題可以忽略。

但在跨 Agent、科學、金融、機器人與長期智慧體系統中，不能永遠忽略。

2. 時間的五層分解

本文提出五層模型：

\boxed{ \text{Physical Source} \rightarrow \text{Reference Timescale} \rightarrow \text{Epoch Encoding} \rightarrow \text{System Transformation} \rightarrow \text{Local Representation} }

2.1 第一層：物理授時來源

物理授時來源回答：

這個時間值最終從哪裡來？

可能包括：

原子鐘集合；
國家級時間實現；
GNSS；
NTP server；
PTP grandmaster；
本地 oscillator；
作業系統 clock；
模擬器 clock。

因此：

\text{source} \neq \text{timescale}

來源是實現與傳遞。

時間尺度是規則。

2.2 第二層：參考時間尺度

時間尺度回答：

這個時間值依照哪一套時間規則成立？

可抽象為：

T_k

不同 $T_k$ 可能具有：

不同連續性；
不同起點；
不同跳秒政策；
不同物理意義；
不同適用範圍。

例如：

T_{\mathrm{TAI}}, T_{\mathrm{UTC}}, T_{\mathrm{UT1}}, T_{\mathrm{GPS}}, T_{\mathrm{POSIX}}

不能被簡化成「只是不同格式」。

2.3 第三層：Epoch 編碼

Epoch 回答：

從哪裡開始數？

令：

E_i

為第 $i$ 個 Epoch。

則：

\tau_i(t)=\Delta_{T_i}(E_i,t)

同一瞬間可具有多個不同的數值表示。

因此：

\tau_A(t)\neq\tau_B(t)

不代表：

t_A\neq t_B

它可能只是編碼不同。

2.4 第四層：系統時間轉換

若系統 A 與系統 B 有不同時間定義，則需要：

\Phi_{A\rightarrow B}

使：

\tau_B = \Phi_{A\rightarrow B}(\tau_A)

最簡單轉換：

\tau_B = a\tau_A+b

但實際轉換可能包含：

leap tables；
calendar rules；
DST rules；
historical timezone changes；
rate changes；
pause intervals；
piecewise mappings；
relativistic corrections；
event-triggered clocks。

2.5 第五層：局部表示

最後一層才是使用者看到的：

2026-07-07 15:30:00；
台北時間；
星期二；
某遊戲世界第 328 年；
某 Agent 生命史第 429 日。

因此：

\text{Human-readable time}

是最外層表示，而不是共同時間本體。

3. 共同參考瞬間

本文定義：

I^\*

為共同參考瞬間。

它不是某個具體字串。

而是一個可被多系統共同指向的事件位置。

各系統可表示：

\tau_i = \Phi_i(I^\*)

因此：

I^\* \rightarrow \tau_A

I^\* \rightarrow \tau_B

I^\* \rightarrow \tau_C

這意味著 Agent A 與 Agent B 不需要使用相同曆法、時區或內部 clock。

只要它們都能回到：

I^\*

就能確認：

我們正在談同一個參考瞬間。

4. 共同時間不是「單一絕對時間」

本文必須避免另一個誤解。

共同時間座標層不等於宣稱：

宇宙存在一個形而上學上的唯一牛頓式絕對時間。

本文的共同時間是：

協議上的共同參考

而不是：

宇宙終極時間本體

這兩者不同。

協議層可以選擇：

I^\*_{\mathrm{ref}}

作為共同參考。

但這不排除：

相對論；
固有時；
重力時間膨脹；
速度差異；
不同參考系。

因此，對更高階物理系統，可以擴展：

\tau_i = \Phi_i ( I^\*, x_i, v_i, g_i, \mathcal F_i )

其中：

$x_i$ ：位置；
$v_i$ ：速度；
$g_i$ ：重力勢；
$\mathcal F_i$ ：參考系資訊。

5. 時間系統的一般形式

本文提出：

\mathcal S_i = ( E_i, \tau_i, r_i, \phi_i, \Pi_i, \Omega_i )

5.1 $E_i$ ：Epoch

系統起點。

5.2 $\tau_i$ ：內部時間座標

系統當前時間值。

5.3 $r_i$ ：相對速率

若：

r_i=1

代表與父系統同速。

若：

r_i=10

代表：

1\text{ parent second} = 10\text{ local seconds}

5.4 $\phi_i$ ：相位偏移

表示系統起始偏移。

5.5 $\Pi_i$ ：政策

包括：

leap policy；
pause policy；
rounding；
overflow；
calendar；
DST；
invalid time；
ambiguity handling。

5.6 $\Omega_i$ ：來源與可信度

包括：

source；
uncertainty；
sync state；
version；
observation time；
provenance chain。

6. 嵌套時間系統

若：

\mathcal S_1 \subset \mathcal S_0

且：

\mathcal S_2 \subset \mathcal S_1

則：

\tau_1 = \Phi_{0\rightarrow1}(\tau_0)

\tau_2 = \Phi_{1\rightarrow2}(\tau_1)

因此：

\tau_2 = \Phi_{1\rightarrow2} \circ \Phi_{0\rightarrow1} (\tau_0)

這提供了一個非常重要的工程與本體論接口：

子系統可以有自己的「相對絕對時間」。

在子系統內：

\tau_i

可作為局部基準。

但它仍然可追溯到父層。

這與嵌套圖論、集合容器時間與分層系統動力學高度相容。

7. 模擬世界時間

假設某遊戲世界：

\mathcal S_G

具有：

自定義 Epoch；
12 倍速；
一天 20 小時；
一年 400 天。

則：

\tau_G = 12(\tau_R-E_G)

但曆法表示又由：

\Lambda_G(\tau_G)

決定。

因此：

\text{Game Date} = \Lambda_G \circ \Phi_{R\rightarrow G} (\tau_R)

這意味著：

「時間轉換」與「曆法格式化」應分離。

8. 暫停、恢復與非連續時間

對 Agent、遊戲與模擬系統，時間可能不是連續流逝。

例如：

r(t)= \begin{cases} 1,& t<t_1\\ 0,& t_1\le t<t_2\\ 1,& t\ge t_2 \end{cases}

則局部時間：

\tau(t) = \int_{t_0}^{t}r(s)\,ds

這可以表達：

pause；
hibernation；
suspended Agent；
paused simulation。

因此一個 AI 可以有：

\text{wall time}

與：

\text{experienced active time}

兩種不同生命史時間。

9. Event Time 與 Wall Time

分散式系統常需要區分：

事件何時發生；
系統何時收到；
系統何時處理。

因此可定義：

t_{\mathrm{event}}

t_{\mathrm{ingest}}

t_{\mathrm{process}}

而未來 Agent 系統還可能需要：

t_{\mathrm{intent}}

表示意圖形成時間。

以及：

t_{\mathrm{commit}}

表示承諾成立時間。

這些時間不必相同。

10. 共同時間與 Agent

對短 session chatbot 而言，時間只是上下文。

但對長程 Agent：

任務有期限；
記憶有先後；
承諾有時間；
因果有順序；
工具操作要追溯；
多 Agent 要同步。

因此 Agent 至少需要：

\mathcal T_A = ( t_{\mathrm{reference}}, t_{\mathrm{local}}, t_{\mathrm{task}}, t_{\mathrm{memory}} )

10.1 Reference Time

共同外部時間。

10.2 Local Time

Agent 所在系統時間。

10.3 Task Time

任務內部時鐘。

10.4 Memory Time

記憶被觀測、寫入與回憶的時間。

這四者不應永遠混為一談。

11. 主體性 AI 與生命史時間

若未來 AI 具備：

高能動性；
持續記憶；
元認知；
長期意圖；
自我模型；
跨任務生命史；

則時間不再只是系統 metadata。

它變成：

主體連續性的基本條件之一

因為：

M_{t_2}

是否能正確理解：

M_{t_1}

取決於：

事件順序；
來源；
時間差；
中間斷裂；
是否休眠；
是否重建；
是否為同一系統實例。

因此：

\text{Identity Continuity}

可能至少部分依賴：

\text{Temporal Continuity}

12. 智慧體共同時間

若多個持續智慧體：

A_1,A_2,\ldots,A_n

各自有局部時間：

\tau_1,\tau_2,\ldots,\tau_n

則共同協作需要：

I^\*

使：

\tau_i = \Phi_i(I^\*)

這不要求它們「感受相同時間」。

只要求：

可以對齊共同事件。

因此：

\text{Shared Time} \neq \text{Shared Experience}

但：

\text{Shared Reference}

是協作前提。

13. 時間來源追溯

本文主張，一個嚴謹時間值應表示為：

\Theta = ( v, u, e, s, r, q, p )

其中：

$v$ ：value；
$u$ ：unit；
$e$ ：encoding；
$s$ ：timescale；
$r$ ：reference/source；
$q$ ：uncertainty/quality；
$p$ ：policy/version。

例如，不能只回：

{
  "value": 1783420000
}

而應支持：

{
  "value": "1783420000.123456789",
  "unit": "second",
  "encoding": "unix",
  "timescale": "posix",
  "reference_scale": "utc",
  "source": {
    "type": "ntp",
    "provider": "example"
  },
  "uncertainty_ns": 2500000,
  "policy": {
    "leap_second": "posix-compatible"
  },
  "observed_at": "..."
}

14. 轉換圖

若時間系統很多，直接維護任意兩點轉換：

\Phi_{i\rightarrow j}

會導致：

O(n^2)

複雜度。

因此可建立：

G_T=(V,E)

其中：

$V$ ：時間系統；
$E$ ：已知轉換。

轉換可透過圖路徑組合：

\Phi_{A\rightarrow D} = \Phi_{C\rightarrow D} \circ \Phi_{B\rightarrow C} \circ \Phi_{A\rightarrow B}

但必須附帶：

誤差累積；
版本；
可逆性；
有效區間。

15. 轉換不是永遠可逆

若：

\Phi_{A\rightarrow B}

涉及：

rounding；
many-to-one mapping；
leap ambiguity；
DST overlap；
truncation；

則：

\Phi^{-1}

可能不存在。

因此 API 必須允許：

{
  "invertible": false,
  "ambiguity": "multiple_candidates"
}

這是嚴謹時間系統的重要條件。

16. Versioned Time

時區規則、政治邊界、曆法政策與 leap policy 可能改變。

因此：

\Phi_{A\rightarrow B}

不應只有名稱。

而應有版本：

\Phi_{A\rightarrow B}^{(v)}

即：

transform_version
tzdb_version
leap_table_version
valid_from
valid_to

因此：

同一時間轉換，在不同規則版本下可能有不同答案。

17. 共同時間 API 的最小本體

本文建議至少存在四個核心概念：

17.1 Instant

共同瞬間。

17.2 Timescale

時間尺度。

17.3 Encoding

編碼。

17.4 Transform

轉換。

可形式化：

\mathfrak T = ( \mathcal I, \mathcal S, \mathcal E, \mathcal F )

其中：

$\mathcal I$ ：instant space；
$\mathcal S$ ：timescale set；
$\mathcal E$ ：encoding set；
$\mathcal F$ ：transform operators。

18. 為何這不只是工程便利？

共同座標系是大型協作系統的前提。

字元系統需要共同編碼。

網路需要共同協議。

地理資訊需要共同座標。

時間也一樣。

若未來存在：

大量 Agent；
多模型調度；
數位孿生；
機器人群體；
長期 AI；
模擬社會；

則：

\text{Temporal Interoperability}

本身可能成為基礎設施。

19. 與嵌套時間理論的關係

本文可與「集合容器時間」對接。

令父層：

\mathcal C_0

具有：

T_0

子層：

\mathcal C_1

具有：

T_1

在 $\mathcal C_1$ 內：

T_1

可作為相對絕對規則。

但相對於父層：

T_1 = \Phi_{0\rightarrow1}(T_0)

因此：

絕對可在局部成立，相對可在層級成立。

這避免了：

純粹絕對論；
純粹相對論；

之間的粗糙二分。

20. 可能的應用

20.1 Agent 協同

多 Agent 事件對齊。

20.2 長期記憶

記憶生命史。

20.3 遊戲世界

自定義曆法與倍速。

20.4 數位孿生

真實／模擬同步。

20.5 機器人

感測器、任務與控制時序。

20.6 科學

不同時間尺度與來源追溯。

20.7 分散式系統

事件時間與處理時間。

20.8 AI 法律責任

行動、授權、承諾、撤回的時間證據。

21. 可檢驗命題

本文提出以下可檢驗命題。

命題一

單一 Unix timestamp 對未來高階 Agent 系統的長期事件對齊不足。

命題二

來源、尺度、政策與版本資訊會成為高風險 AI 系統的重要時間 metadata。

命題三

長期 AI 記憶系統將需要區分 wall time、active time、task time 與 memory time。

命題四

自定義時間轉換圖將成為模擬器、數位孿生與多 Agent 系統的通用接口之一。

命題五

主體性 AI 若出現，時間連續性將成為其生命史與責任模型的重要變數。

22. 可能的反對意見

22.1 「這只是 NTP 加時區轉換」

不完全是。

NTP 解決授時。

本文還處理：

timescale；
epoch；
provenance；
custom systems；
transform graph；
nested clocks；
Agent history。

22.2 「全部用 UTC 就好了」

UTC 是重要共同尺度，但不等於所有應用層時間。

例如：

模擬時間；
active time；
GPS time；
event time；
local civil time。

仍需轉換。

22.3 「Agent 不需要自己的時間」

短期 Agent 可能不需要。

持續存在、跨 session、跨年度的 Agent 很可能需要。

22.4 「共同參考瞬間是假絕對時間」

不是。

它是協議參考。

不是宇宙終極本體。

23. 結論