記錄您用來產生 Discord 時間戳的步驟，代表要把每一個輸入、形塑該輸入的裝置設定，以及所選的樣式代碼都寫下來，如此一來工作流程才能重複執行、被稽核，或交棒給其他人。Discord 時間戳是一段標記字串，例如 <t:1783915200:F>，但產生它的過程 ── 也就是輸入的本機日期、用於解讀的作業系統時區、訊息鎖定的閱聽對象，以及選擇簡潔或詳細樣式的原因 ── 這類資訊在聊天紀錄捲過去之後就消失了。一份簡短的書面紀錄能捕捉到螢幕截圖無法保存的內容。Discord 時間戳產生器只要輸入一組本機日期與時間，就能在瀏覽器中完整產出可直接複製的一組資料列，這讓您可以把工作流程跟同一場活動的筆記一起記錄下來。本指南涵蓋要記錄哪些內容、按照什麼順序，以及如何格式化這些筆記，讓它們在下一次有活動需要同類標記時仍然派上用場。
為什麼書面紀錄對 Discord 時間戳產生至關重要
Discord 時間戳產生器針對其所列的每一種樣式代碼，都會輸出同一個 Unix 秒數，因此流失資訊的並不是標記本身，而是圍繞在外的脈絡。一則只寫著 <t:1783915200:F> 的紀錄，對審閱者而言完全無法得知 1783915200 對應的是中午還是午夜，或者撰寫者當時思考的是太平洋時間還是主辦城市的當地時區。等到問題被提出來查看書面紀錄時，原始訊息很可能已經被編輯、刪除，或被移到其他頻道，而產生時間戳的裝置往往也不是審閱者正在使用的同一台裝置。
書面步驟在活動變動時也很有幫助。當活動需要重新發布一則修正過的時間戳時，如果前一則紀錄已經列出閱聽對象的地區、預定顯示的樣式，以及原始的本機時間點，整個過程就會更快。少了那份紀錄，唯一能取回同一個 Unix 秒數的方法，就是從頭重做每一項假設，而這正是書面化工作流程所要避免的錯誤類型。Discord 時間戳產生器完全在瀏覽器中執行，既不會上傳所選的日期、Unix 秒數，也不會上傳標記內容，因此書面化的步驟可以由撰寫者自行選擇存放位置 ── 例如筆記應用程式、團隊 Wiki、commit 訊息，或公告草稿本身的留言中。
文件中值得記錄的輸入項目
一份實用的紀錄，要從工具本身並未顯示的那些輸入開始。瀏覽器會依據作業系統所設定的時區(含所有日光節約規則)來解讀日期與時間的輸入，因此時區本身就是輸入的一部分。把裝置名稱、時區縮寫，以及產生當下的 UTC 偏移量記錄下來，就能提供審閱者重現該時間點所需的原始資訊。閱聽對象所在的地區即使與撰寫者的地區相同也應記錄，因為 Discord 會依每位檢視者的語系與時區來呈現同一個 Unix 秒數 ── 這項事實正是該工具設計方式的基礎，但仍應該寫進筆記裡，以免日後重新整理時被遺忘。
顯示在每一列旁邊的 Unix 秒數，是把每一種樣式串連在一起的單一數值，值得將它當作獨立數字記錄下來。若後端系統、機器人或其他產生器針對看似相同的活動產生了不同的 Unix 秒數，差異幾乎都是時區假設不同所造成的，而不是工具的 bug。分開記錄 Unix 秒數，就能讓這種比較變得直接。每種樣式的預定用途 ── 相對時間提醒、精簡的行事曆項目、完整的活動標頭 ── 是最後一項要記錄的輸入，因為樣式的選擇只會改變呈現方式，絕不會改變時間點本身。
如何記錄工作流程中的每一步
- 開啟工作流程要存放的筆記檔案或 Wiki 頁面，在頁面頂端記錄今天的日期、您的裝置、您的作業系統時區及其目前的 UTC 偏移量，以及該公告鎖定的閱聽對象地區。
- 在相同的瀏覽器工作階段中開啟 Discord 時間戳產生器，讓瀏覽器的本機時區規則與您剛才記錄的內容一致。
- 在本地日期時間欄位中輸入活動的日期與時間，並把您輸入的值以純文字寫進筆記(例如「2026-07-13 12:00 local」)。
- 產生資料列組，並把標記旁邊顯示的 Unix 秒數複製到筆記中;這個值就是定義活動時間點的依據，與樣式無關。
- 對於每一種您可能會貼上的樣式代碼，把對應的資料列複製到筆記中，並在旁邊標註它在訊息中扮演的角色(提醒、標頭、行事曆項目，依此類推)。
- 把其中一個偏好的資料列貼到 Discord 訊息草稿中，讓標記保留在反引號之外，並在儲存草稿前先確認 Discord 在您的帳號上呈現出預期的時間。
- 若有第二位審閱者參與，把草稿傳給該審閱者，請他們用自己的語系回報所呈現的時間，並把他們的回覆記錄在書面步驟旁邊。
- 為筆記加上產生日期與閱聽對象地區作為版本標記;每當活動時間變動時就重新產生資料列組，並就地更新筆記，而不要附加第二份紀錄。
九種樣式代碼及其各自傳達的內容
Discord 時間戳產生器會列出 Discord 目前文件集中所有的代碼，連同省略樣式字母的預設形式也一併列出。根據 Discord 的訊息格式參考文件以及 discord.js 的 TimestampStyles 變數，這些代碼對應到固定的呈現規則，因此記錄您使用的是哪一種，也就等於記錄了讀者將看到的呈現類型。若想更仔細了解如何把每一列複製到訊息中，複製九種 Discord 時間戳樣式標記的指南針對同一組樣式提供了操作範例。
| 代碼 | 名稱 | Discord 呈現的內容 | 書面化角色 |
|---|---|---|---|
| (無) | 預設 | 長日期、短時間(等同 f) | 未指定樣式時的一般公告 |
| t | 短時間 | 僅顯示時鐘時間 | 長訊息中的精簡提醒 |
| T | 中等時間 | 時間加上簡短的時區後綴 | 跨時區時不需完整日期的清楚標示 |
| d | 短日期 | 精簡的數字日期 | 行事曆表格與清單 |
| D | 長日期 | 含星期幾的完整日期 | 需要完整日期的活動標頭 |
| f | 長日期短時間 | 長日期加上簡短的時鐘時間 | 等同預設的明確版本 |
| F | 完整日期短時間 | 星期幾加上完整日期再加上短時間 | 詳細的規劃公告 |
| s | 短日期短時間 | 短日期加上短時間 | 精簡的行程列 |
| S | 短日期中等時間 | 短日期加上中等時間 | 需要時區提示的行程列 |
| R | 相對時間 | 相對於該時間點的時長 | 隨時間經過會自動更新用詞的提醒 |
記錄的是「角色」而不只是代碼，才能讓未來貢獻者在同一活動改用不同樣式時，這份紀錄依然有用。Unix 秒數在每一列都維持不變，因此即使所選樣式不同，書面化的時間點也不會漂移。
記錄特殊情況:日光節約與重複的時間點
在任何書面化的工作流程中，有兩種情況值得單獨記錄:一是春季快進導致某個本機時間被略過的空檔，二是秋季倒退造成同一個本機時間出現兩次的重疊。工具會拒絕不可能的日期，但瀏覽器最終會套用作業系統的本機時區規則，因此看起來有效的日期，在時鐘變更前後仍可能對應到令人意外的時間點。記錄當時輸入的是哪個時鐘值，以及該裝置在那一刻的 UTC 偏移量，審閱者就能檢查 Unix 秒數是否真的對應到預定的日期時段。若是發生在時鐘變更前後的重要活動，在書面步驟被視為定案之前，請先與目標時區的某人確認貼上後的結果。
跨時區活動會帶來另一項相關的細節:撰寫者的裝置可能設定在某個時區，而活動場地或閱聽對象卻在另一個時區。記錄「撰寫者預期使用的時區」，比記錄「裝置當時剛好所在的時區」更有用，因為撰寫者可以修正裝置並重新產生，但閱聽對象看不到撰寫者腦中的想法。像「12:00 local = 預期為場地時間 12:00，裝置時區 America/New_York」這樣的註記，能提供審閱者一切所需，在公告發出前及早發現不吻合。對於撰寫者與閱聽對象經常位於不同時區的活動，為跨時區活動設定 Discord 時間的指南提供了同類型紀錄的可重複流程。
與團隊分享書面化的工作流程
當同個社群由不只一個人負責產生 Discord 時間戳時，書面化的步驟就成為一份共用的 runbook。採用簡短且固定的結構會很有幫助:開頭是裝置時區與閱聽對象地區的標頭，接著是上述八個步驟的編號清單，然後是依角色標註的產生資料列片段，最後是審閱者以其自身語系所見呈現時間的回覆。Markdown 很適合使用，因為 Discord 與大多數 Wiki 都能直接渲染，而在標記資料列外圍加上圍欄式程式碼區塊，既能讓角括號保持可見，又不會被迫在反引號中再嵌入反引號。把 runbook 與公告草稿放在一起儲存，而不是放在另一個獨立的知識庫，能讓紀錄緊鄰著它所說明的訊息，而這往往正是下一位貢獻者第一個查看的地方。
Discord 時間戳產生器本身並不會連線到 Discord、檢查伺服器、發送訊息，或驗證特定客戶端如何呈現結果，因此 runbook 必須明確包含「呈現後的確認」這個步驟。一份省略審閱者回覆的紀錄是不完整的，因為 Discord 的在地化結果實際上只有 Discord 內部才看得到。針對持續性的文件，請把 runbook 視為有版本的內容:當 Discord 演進其格式規則時，所引用的參考來源才是語法與意義的權威依據，而 runbook 應該被更新，而不是被改寫。