選擇正確的方式來透過 Discord 時間戳記產生器 產生 Discord 時間戳記，意味著要挑選符合你訊息用途的樣式代碼，而不是挑選不同的時間點。產生器輸出的每一個結果都共用同一個 Unix 秒數;只有顯示方式會改變。你的工作是決定讀者需要的是簡潔的時鐘時間、較完整的行事曆日期，還是會隨著時間流逝而變動的相對時間描述。接著 Discord 會依每位檢視者的語系與時區來呈現你所選擇的樣式，因此同一段標記在當下對柏林的一位隊友和聖保羅的一位朋友看起來都正確。產生器會輸出預設形式以及目前有記載的九個樣式代碼——t、T、d、D、f、F、s、S 和 R——並附上原始的 Unix 秒數以便驗證。因此，選擇正確的方式其實就是一個依照情境搭配樣式、確認裝置時區，然後把標記貼到 Discord 中且不要使用會抑制渲染的程式碼區塊的問題。
為什麼樣式選擇會影響 Discord 呈現時間的方式
Discord 時間戳記中所嵌入的 Unix 秒數是固定的。產生器兩個輸出列之間的差異，在於冒號後所附加的那一個字母或大寫字母，而 Discord 的說明文件明確寫出了每個字母所代表的輸出。預設形式省略樣式代碼，效果等同於 f 的「完整日期、短時間」呈現方式。加上 t 會要求 Discord 顯示簡短的時鐘時間，例如「21:00」，而 T 則再加上秒數。d 與 D 代碼以行事曆資訊取代簡潔性，f 與 F 混合日期與時間並提供不同程度的細節，s 與 S 是短日期加時間的變化，而 R 是唯一會隨著時間改變措辭的樣式(例如「3 小時後」、「2 天前」)。
由於最終呈現由 Discord 控管，實際措辭會依檢視者的語言、裝置與當下時間而有所不同。產生器只提供可直接複製的標記，而不是假裝某個瀏覽器的預覽結果能代表所有 Discord 客戶端。這就是為什麼「選擇正確的方式」多半是一個關於呈現的判斷:底層的時間點在不同時區之間依然可攜，但聊天中實際顯示的字元，完全取決於你貼上的樣式代碼以及每位讀者的設定。
九種 Discord 時間戳記樣式一覽
請利用下表比較每個有記載的樣式代碼會產生什麼、最適合用於什麼情境，以及與其他樣式有何差異。這些代碼來自 Discord 目前的訊息格式參考資料，而每一列都對應到產生時所選擇的同一個 Unix 秒數。
| 樣式代碼 | Discord 顯示內容 | 最適合用途 |
|---|---|---|
| (預設) | 完整日期、短時間(等同於 f) | 同時包含日期與時間的平衡型公告 |
| t | 短時間，例如「21:00」 | 日期已知的快速提醒 |
| T | 含秒數的短時間 | 賽事開始或倒數等精確時刻 |
| d | 短日期 | 僅需提到日期層級的參考，例如「7/13 一起來」 |
| D | 完整日期 | 正式的邀請與活動頁面 |
| f | 完整日期、短時間 | 同時含日期與時間的會議邀請 |
| F | 完整日期、含星期的短時間 | 需要額外脈絡的詳細公告 |
| s | 短日期、短時間 | 跨時區的簡潔訊息 |
| S | 短日期、中等時間 | 短日期搭配中等時間的詳細訊息 |
| R | 相對時間，例如「2 小時後」 | 措辭應隨時間更新的提醒 |
依訊息用途挑選樣式
挑選正確方式最可靠的方法，從讀者的任務出發，而非從樣式清單出發。在複製任何一列之前，先問三個問題。
- 讀者需要的是行事曆參考，還是時鐘時間? 行事曆參考(D、F、d)會把訊息錨定在某個日期。時鐘參考(t、T)則會把訊息錨定在某個已知日期內的特定時間點。
- 措辭是否應該隨時間經過而改變? 只有 R 會更新顯示，因此提前一週發出的提醒，今天看起來是「7 天後」，明天則變成「2 小時後」。其他樣式的文字則保持穩定不變。
- 訊息可以佔用多少水平空間? 簡潔樣式(t、d、s)能讓聊天在行動裝置上保持易讀。詳細樣式(D、F、S)則適合用於公告、嵌入訊息或置頂訊息。
對於跨多個時區閱讀的社群活動、遊戲時段、發布、維護時段、課程、實況、會議與截止時間，使用絕對樣式通常較安全，因為讀者可以隨時掃讀日期而無需心算。把 R 留給像「團隊副本將在 30 分鐘後開始」這類相對措辭本身就是重點的提醒。
如果你的公告同時包含穩定的日期與相對倒數，請從同一個時間點產生兩列:日期那行挑選一種絕對樣式，提醒那行則使用 R。兩列帶有同一個 Unix 秒數，因此彼此之間不會產生偏移。
如何產生並套用正確的時間戳記
- 確認裝置上的時區。 開啟作業系統的日期與時間設定。如果你預期使用的是某個場地的時區而非目前所在時區，請先切換;產生器會讀取瀏覽器的本地時區設定。
- 選擇活動的日期與時間。 在日期時間欄位中輸入預期的本地時間。若活動時間接近日光節約轉換，請務必再次確認，因為最終會由作業系統套用本地時區規則。
- 產生完整組合。 工具會從同一個時間點產生預設標記、所有九種有記載的樣式，以及底層的 Unix 秒數。
- 檢查 Unix 秒數。 Unix 秒數是指自 1 January 1970 UTC 起所經過的秒數。檢視這個數字可以幫助你快速驗證換算結果，並在需要時與其他系統比對。
- 挑選最適合訊息的樣式。 僅顯示時間的提醒使用 t 或 T;完整公告使用 D 或 F;簡潔的日期加時間使用 s 或 S;僅顯示日期使用 d;相對措辭使用 R。
- 複製所選的那一列，貼到 Discord 中。 除非你刻意希望 Discord 顯示原始字元而非渲染時間戳記，否則不要用程式碼區塊或反引號包起來。
- 在發送重要公告前確認渲染結果。 Discord 的檢視者本地化顯示代表你的預覽不會與其他客戶端的文字完全一致，但你仍可以驗證時間戳記有顯示出來、日期是你所選的那一天，且相對措辭合理。
- 每當活動時間變更時，請重新產生。 切換不同樣式並不會改變活動時間，因為每一列共用同一個 Unix 秒數。若活動時間本身變更，則必須以新的本地時間重新產生一組。
時區、日光節約與其他影響方式的因素
樣式選擇只是「正確方式」的一半。另一半則是確保 Unix 秒數真正指向你所預期的那個時鐘時刻。由於欄位使用的是你裝置的本地時區規則(包括任何日光節約偏移)，時區設定錯誤會產生相差一小時或一個日光節約空檔的 Unix 秒數。產生器會拒絕不可能的日期組合，但作業系統仍會套用本地時區，因此在春季提前或秋季延後的模糊本地時刻，可能會落在錯誤的絕對時間點。
對於接近時鐘變更的重要活動，請與目標時區的某人確認貼上後的結果。一個簡單的健全性檢查是把 Unix 秒數讀出來再換算回去:除以 86,400 取得總天數，從 1 January 1970 紀元起算那些天數以得出日期，然後取一天中的剩餘小數乘以 24 來還原 UTC 小時。例如，1,783,915,200 ÷ 86,400 ≈ 20,647.17 天。從紀元起算 20,647 個整天會落在 13 July 2026，而剩餘的 0.17 天約再加四小時，得到 04:00 UTC。如果你在那個時區的隊友看到的是預期的時鐘時間，代表換算正確。
隱私與可靠度同樣會影響「正確方式」的判斷。一切都在瀏覽器本地執行:所選的日期、Unix 秒數與 Discord 標記都不會被上傳，工具也不會連線到 Discord、檢查伺服器、發送訊息、排定活動，或驗證特定客戶端的渲染結果。這讓產生過程既快速、私密且易於稽核，但也表示樣式驗證仍須在 Discord 本身進行。
挑選樣式時常見的錯誤與預防方法
大多數挑選樣式的錯誤來自複製貼上的習慣，而非來自產生器。把標記包在反引號或程式碼區塊中，會讓 Discord 顯示原始字元而非渲染時間戳記，這也是剛產生的那一列「無法生效」最常見的原因。請將標記直接貼到一般的 Discord 訊息中。
另一個常見錯誤是誤以為切換樣式會改變活動時間。樣式只改變呈現方式;底層的 Unix 秒數維持不變。複製其他樣式並不會移動活動時間。若活動本身時間已更改，請以新的本地時間重新產生。
最後，不要只靠單一瀏覽器的預覽來證明所有 Discord 客戶端的渲染結果。實際文字會依檢視者語言、裝置與當下時間而有所不同，Discord 也可能演進其格式規則。所引用的 Discord 開發者文件中的訊息格式章節 是語法與意義的權威來源，而 discord.js TimestampStyles 參考資料 描述的是同一組代碼。此工具僅限於目前有記載的樣式，不會自行猜測別名。請把產生器視為精準的標記來源，而把 Discord 實際渲染結果視為可見措辭的唯一真實依據。
若想更仔細查看九種輸出格式中的每一種，請參考 Discord 時間戳記產生器:複製九種樣式的標記 指南，逐列說明每一行;而 如何在發送前檢查 Discord 時間戳記結果 指南則詳細說明了最後的驗證步驟。