Discord 時間戳是一段標記語法，它會把一個 Unix 秒數包在角括號內，像 <t:1783915200:F>，這樣 Discord 就能依每位讀者所在的當地時區顯示該時間。若想設定一條所有觀看者都能正確看到的 Discord 時間，只要把那段標記直接貼到訊息中即可 —— Discord 會讀取內嵌的 Unix 秒數作為精確的瞬間，再依每位讀者的語言、地區與時區，自動決定顯示出來的文字內容。在一個橫跨多洲的頻道裡寫下「July 13 at noon」，結果往往只能憑猜測；柏林的某位讀者看到的時鐘，和聖保羅的某位讀者看到的時鐘並不相同。相比之下，Discord 時間戳永遠指向同一個瞬間，而平台會負責轉換。產生時間戳的最快方式是使用 Discord 時間戳產生器，它會把你裝置當地時區的日期與時間，一次轉換成預設標記加上全部九種現有樣式代碼。然後複製符合你要的顯示效果的那一列，貼到你的訊息草稿中，傳送前再確認一次渲染後的預覽。
Discord 時間戳存在的目的，正好是純文字日期會不夠用的情境：社群活動、遊戲場次、上線時段、排定維護、課程、實況、會議、截止期限，以及任何會被不同地區的人讀取的訊息。每位觀看者看到的都是同一個瞬間，但螢幕上的文字會配合各自的時鐘與語言，省去「等等，這是你的時間還是我的時間？」來回確認的麻煩。
為什麼 Discord 時間戳不同於直接輸入日期
當你在 Discord 訊息中以純文字輸入日期時，每位讀者都會用各自的脈絡去解讀。東京的成員看到「8 PM Friday」會預設是 JST；多倫多的版主會預設是 EDT；剛醒來的新成員可能在幾小時後才讀到，並轉換錯誤。結果就是時間出現落差，這與 Discord 本身無關，完全取決於人類腦中如何記憶時間。
Discord 時間戳透過把內容對齊到單一 Unix 秒數，避開了這種落差。Discord 儲存那個秒數，再依每位觀看者的地區與時區渲染顯示文字。不同時區的兩位讀者會看到不同的時鐘數字，但他們看到的是同一個瞬間。Discord 開發者說明文件列出支援的樣式代碼，並確認內嵌的 Unix 秒數才是 Discord 用來作為真相來源的依據。
當社群有排定活動時，實際效益立刻顯現出來。你不用請所有人做心算，只要寄出一段標記字串。Discord 負責轉換，而訊息對每位讀者讀起來都很自然。
九種 Discord 時間戳樣式及其顯示內容
Discord 目前在文件中記錄了九種時間戳樣式，外加一個省略樣式代碼的預設值，渲染效果等同於 f 的完整日期、簡短時間。樣式只控制呈現方式；每一組產生出的列都指向同一個 Unix 秒數。從 t 換成 F 並不會移動事件時間，只是改變觀看者看到的細節多寡。
| 代碼 | 名稱 | 觀看者看到的內容 |
|---|---|---|
| (default) | 預設 (等同 f) | 完整日期、簡短時間，無樣式旗標 |
| t | 簡短時間 | 僅時間，精簡 |
| T | 中等時間 | 含秒數的時間 |
| d | 簡短日期 | 僅數字日期 |
| D | 完整日期 | 完整拼寫的日期 |
| f | 完整日期簡短時間 | 日期加上精簡時間 |
| F | 完整日期簡短時間 | 含星期幾的完整日期與時間 |
| s | 簡短日期簡短時間 | 數字日期與時間 |
| S | 簡短日期中等時間 | 含秒數的數字日期與時間 |
| R | 相對時間 | 「in 3 hours」/「2 days ago」，Discord 會隨時間自動更新 |
樣式代碼區分大小寫。discord.js TimestampStyles 參考確認了與官方文件相同的一套樣式，官方文件才是語法的權威來源。任何不在這份清單上的別名都無法保證能如你所預期地渲染，所以產生器只會輸出這些有文件記載的代碼。
如何使用產生器設定 Discord 時間
從本機時鐘顯示，到一條在各地都能正確渲染的 Discord 訊息，產生器是最快的途徑。三個步驟就能涵蓋完整流程。
- 在你裝置的當地時區中選擇事件日期與時間。開啟 Discord 時間戳產生器，輸入你想公告的瞬間。輸入欄位會使用你作業系統目前設定的時區，所以在輸入前請再次確認該時區 —— 若你要採用的是活動場地的時區而非你目前的時區，請先切換裝置或調整系統時鐘。
- 產生預設標記、全部九種有文件記載的樣式，以及 Unix 秒數值。工具會從你輸入的單一瞬間產生一整套結果。如果你想要和另一個以秒為單位儲存時間的系統做比對，可以檢查 Unix 數字。樣式選擇只會改變呈現方式；每一列編碼的都是同一個秒數。
- 複製要使用的那一列，貼到 Discord 中，並在傳送前確認渲染後的時間。把標記直接貼到訊息草稿中，不要用反引號包起來，除非你刻意要 Discord 顯示原始字元。在私人頻道中先送出一則測試訊息，確認渲染後的時間戳符合預期，特別是當事件落在日光節約時間的轉換點附近時。
只要事件時間有變動，就重新產生一次。標記內的 Unix 秒數會跟著你的輸入走，所以只要編輯日期並重新產生，就能取得更新後、可直接複製的值，不必手動計算。
相對樣式與絕對樣式：該用哪一種
R 是唯一一個不會顯示固定時鐘數字的樣式。Discord 會把 R 顯示成像「in 2 hours」或「3 days ago」的片語，並隨著時間經過自動更新文字。這讓 R 成為提醒、倒數，以及「即將開始」通知的絕佳選擇，因為不管讀者是今天還是明天讀到訊息，相對的表達方式都仍然有意義。
絕對樣式 (t、T、d、D、f、F、s、S) 會在觀看者閱讀當天把文字凍結起來。當讀者需要穩定的行事曆參考點時，請使用絕對樣式 —— 例如釘選在頻道中的會議邀請、遊戲更新的上線日，或是某項服務的維護時段。較詳細的 F 與 S 提供更多可見的脈絡 (星期幾、秒數)，而 t、d、s 則保持簡潔。依頻道需求挑選適當的細節程度，但請記住背後指向的瞬間在所有列中都完全相同。
如果你想同時支援習慣相對思考的讀者，以及把日期釘在行事曆上的讀者，可以在同一則訊息中放入兩個時間戳 —— 一個 R 負責倒數，一個 f 負責鎖定日期。兩者來自同一組產生結果，因此秒數天生就會對齊。
應避免的時區與日光節約時間陷阱
Discord 時間戳看起來錯誤最常見的原因，在於產生器使用的時區，與公告預期使用的時區不一致。欄位會讀取你裝置設定的時區，所以若你的筆電因為旅行、日光節約規則或手動調整而飫到別的時區，你產生的每個值都帶著那個飫移。發布前請先確認時區。
日光節約時間的轉換製造了第二個更尖銳的陷阱。在時鐘向前撥快的那晚，某些時區根本不存在 2:30 AM 這種本地時間；在時鐘往回撥慢的那晚，1:30 AM 會出現兩次。產生器會拒絕不可能的日期，但最終仍是由瀏覽器套用作業系統的本地規則。若事件正好排在轉換時點，請在對外公告前，先和身處預定地區的人確認渲染後的結果。
渲染後的時間戳出現差一小時的讀數，幾乎都可以追溯到這兩種原因之一：裝置時區錯誤，或瀏覽器對日光節約時間邊界的解讀與你的預期不同。請把產生器輸出中的 Unix 秒數值視為唯一標準瞬間 —— 不論你貼的是哪一列，所有指向該秒數的 Discord 樣式都會解析為同一個瞬間。
整個工作流程都是在瀏覽器中於本機執行。你輸入的日期、工具計算出的 Unix 秒數，以及它產生的標記都不會被上傳。如果你想在傳送前確認草稿，請把標記貼到私人頻道或測試伺服器，自己讀回渲染後的時間戳。這最後一次的讀回檢查，是防止公開時程出錯最便宜的保險。
如果你正在權衡選項，Discord 時間戳產生器是否會發送訊息？對此有詳細說明。