要開始使用 Discord 時間戳記產生器，請先在裝置的本地時區中選擇事件日期與時間，產生預設標記以及九種已記載的顯示樣式，複製符合訊息內容的那一行，然後直接貼到 Discord 頻道中，這樣每位檢視者就能以自己的地區設定看到該瞬間。整個流程都在你的瀏覽器中執行，熟悉這三個步驟後只需要不到一分鐘，而且不需要 Discord bot、第三方網站的帳號，也不需要上傳任何資料。在背後，這個工具會將日曆輸入轉換為一個完整的 Unix 秒數，並把該數字包進 Discord 的 <t:...:style> 標記中——這是 Discord 官方訊息格式指南唯一認可用於動態時間戳記的語法。由於 Unix 秒數是唯一的事實來源，同一段貼上的標記在紐約的檢視者眼中會顯示為「July 13, 2026 12:00」，在柏林的檢視者眼中則會顯示為「July 13, 2026 18:00」，完全不需要你手動轉換。這個特性正是為什麼在第一次發布跨時區事件時值得學會這套流程，而本指南的其餘部分會按照初次使用者的自然操作順序逐步說明。
這個工具實際上會產生什麼
Discord 時間戳記產生器不是一個一鍵「產生時間戳記」的小工具——它是一個小型標記工廠。它從一個本地瞬間產生一整個預先格式化字串的表格，每一個字串都指向同一個 Unix 秒數，但各自套上不同的顯示樣式。輸出列始終包含固定格式與變動格式，其中固定格式省略了可選的樣式代碼，行為等同於「長日期短時間」，另外還包含 Discord 說明文件所定義的九種現行樣式代碼。另一獨立的列會顯示原始的 Unix 秒數值，這在你想要把該瞬間與其他系統比對、把數字丟進 bot 指令，或在發布前稽核結果時特別有用。由於每一列都帶有相同的 Unix 秒數，你可以用任何順序嘗試不同樣式，而完全不會更動事件時間本身。
開始前先準備好你的裝置
最常見的初次錯誤，就是在裝置時鐘設定錯誤的時區時產生標記。產生器會依照作業系統所回報的時區，把日曆輸入解析為本地時間，因此一台設為太平洋時間的時區筆電，與一台設為東部時間的筆電相比，所產生的 Unix 秒數會無聲無息地相差三小時。在你產生任何東西之前，請先打開系統時鐘設定，確認時區符合你真正想表達的瞬間。如果你要為其他地區的使用者安排事件，請先決定要以誰的本地時鐘輸入——這個工具沒有時區選擇器，而「設定」不同時區的唯一方法，就是改變瀏覽器所認知的本地時間。
日光節約時間的切換需要另外特別說明。瀏覽器會遵循作業系統的規則，這表示在「春季向前調」當天的當地凌晨 2:30 實際上並不存在，而「秋季向後調」當天的同一時間則會出現兩次。雖然這個工具會拒絕不可能的日曆日期，但兩個有歧異的本地時間中哪一個會勝出，仍是由裝置規則決定。對於發生在時鐘切換前後的重要事件，請在廣為宣布之前，先和位於目標地區的人確認貼上的 Discord 時間戳記。
產生你的第一個 Discord 時間戳記
最簡單的做法，就是在瀏覽器中開啟 Discord 時間戳記產生器，依序完成三個動作：輸入一個本地瞬間、複製一列、貼到 Discord 中。下方有序清單會把每個動作展開為初次使用者實際執行的具體步驟。
- 在你的瀏覽器中開啟 Discord 時間戳記產生器。
- 確認裝置的時區符合你想要發布的瞬間（請參考上一節）。
- 在本地日期與時間欄位中輸入事件日期與時間——例如 2026 年 7 月 13 日中午 12:00。
- 產生組合。工具會將日曆輸入轉換為完整的 Unix 秒數，並顯示預設標記、九種樣式列，以及原始的 Unix 數值。
- 看一眼 Unix 秒數那列，確認其量級對你輸入的日期而言是合理的（2026 年 7 月的瞬間大約落在 1.7–1.8 billion 範圍）。
- 挑出樣式最符合訊息內容的那一列——f 適用於平衡的長日期加短時間，R 適用於「in 3 days」這類相對時間用語，t 適用於精簡的時鐘讀數，F 適用於完整拼寫的日曆項目，依此類推。
- 將所選的列複製到剪貼簿。
- 將標記直接貼到 Discord 訊息中——不要加程式碼區塊，也不要加行內反引號，除非你真的想顯示原始字元。
- 將訊息傳給自己或傳到一個草稿頻道，肉眼檢視渲染後的時間，確認它符合你要的瞬間，再發布正式的公告。
為你的訊息選擇合適的樣式
樣式的選擇僅影響呈現方式——每一列都指向同一個 Unix 秒數，因此切換樣式永遠不會改變事件本身。決策的重點在於該列在訊息中讀起來應該是什麼感覺。下面的表格整理了九種並記載的代碼、Discord 對每種代碼的渲染結果，以及典型的使用情境，讓第一次的選擇不再是憑感覺。
| 樣式代碼 | Discord 渲染結果 | 最適合用途 |
|---|---|---|
| t | 短時間，例如 12:00 | 在較長句子中以精簡方式嵌入的提醒 |
| T | 中等時間，例如 12:00:00 | 需要顯示秒數的記錄或排程工作貼文 |
| d | 短日期，例如 13/07/2026 | 列表式公告中精簡的日期參考 |
| D | 長日期，例如 13 July 2026 | 口語化文章中拼出月份讀起來更順的貼文 |
| f | 長日期加短時間（預設） | 通用事件，第一次嘗試時最安全的選擇 |
| F | 完整日期加短時間並含星期 | 重要公告與直播開始時間 |
| s | 短日期加短時間 | 版面緊湊時精簡的「日期加時鐘」組合 |
| S | 短日期加中等時間 | 在狹窄行內需要顯示秒數的技術性貼文 |
| R | 相對時間（「in 3 days」、「2 hours ago」） | 倒數、截止期限、「we go live in...」這類預告 |
對於絕對的日曆參考——例如發布日期、維護時段、開課時間——請選擇絕對樣式，例如 f、F 或 D。對於動態倒數——例如「raids in 10 minutes」——請選擇 R，因為 Discord 會隨著時間經過自動更新渲染出的措辭，而不需要你編輯訊息。詳細樣式 F 與 S 提供最多可見資訊；精簡樣式 t、d 與 s 則讓單一訊息串保持整潔。當你熟悉之後想要更深入的逐樣式比較，挑選合適樣式指南會介紹更多訊息類型。
貼到 Discord 並進行驗證
貼上是步驟最少的一步，卻也是最常被搞砸的一步。標記必須以純文字形式進入訊息本文，不能用程式碼區塊包起來，也不能用單個反引號圍住。程式碼區塊是在告訴 Discord 「顯示原始字元」，而行內反引號在小範圍上效果相同。結果就是你的讀者看到的會是 <t:1783915200:F>，而不是一個時鐘——這看起來就像壞掉的連結。貼上後稍等片刻讓 Discord 渲染，再判斷結果。
如果你有草稿頻道或私人伺服器，這裡是最便宜也最方便的驗證場所。你貼上的瞬間，Discord 就會把 Unix 秒數解析為你所在地區設定的日期與時間。若要快速確認背後的瞬間是否正確，可將游標移到渲染後的時間戳記上或點選它——大多數 Discord 客戶端會以工具提示顯示絕對的本地時間。這個工具提示同樣是由 Discord 從同一個 Unix 秒數產生，因此你在自己時區看到的「1:00 PM」工具提示，與位在東邊三個時區的同事看到的「7:00 PM」工具提示，指的其實是同一瞬間。如果你們雙方的工具提示在時差上是一致的，那麼這段標記就是正確的，公告也可以準備發送了。
這個工具不會做的事
初次使用者有時會以為這個產生器會直接與 Discord 對話。並不會。沒有任何網路呼叫、API 請求、訊息排程，也沒有伺服器稽核。所有流程——日曆解析、Unix 轉換、標記渲染——都在瀏覽器中完成，日期、時間與產生的標記都不會上傳到任何地方。這個工具也不會驗證特定 Discord 客戶端的渲染結果：最終各地區設定的措辭由 Discord 掌控，且支援的樣式僅限於 Discord 現行記載的九種代碼，相關內容請參考 Discord 訊息格式參考文件. 若 Discord 新增了樣式，產生器並不會為它創造別名。若想完整了解哪些輸出對應哪些顯示，請參考複製九種樣式標記指南。
常見的初次問題與修正方式
初次使用時遇到的問題大多可以歸納為三類。第一種是「時間差了一小時」——這是你的裝置時區，包含任何日光節約時間的偏移，洩漏到了 Unix 秒數中。請打開系統時鐘，修正時區，然後重新產生。第二種是「Discord 顯示原始標記」——那是因為反引號或程式碼區塊把該列包起來了；請移除它們並重新傳送。第三種是「隊友看到不同的時鐘」——這其實是功能正常運作的表現；Discord 會以每位檢視者的地區設定渲染同一個 Unix 瞬間，所以不同時區出現不同的時鐘文字是預期行為，並不是錯誤。如果同一時區的兩個人持續看到不同的時間，那就是底層的 Unix 秒數並不一致，問題在產生端而非顯示端——請重新輸入本地瞬間，複製新的一列，再重新傳送。