Unix 時間戳部落格
關於 Unix 時間戳、紀元時間、時區處理、JavaScript Date、資料庫儲存選擇,以及時間轉換引發的生產 bug 的詳細指南。
Linux Time Converter: Unix date Command Guide
Use Linux date commands to convert Unix timestamps fast: epoch to date, date to epoch, current Unix time, milliseconds, UTC output, TZ-based local time, and macOS/BSD equivalents.
閱讀文章 →End of 2026 Unix Timestamp: 1798761600 (and Why Not 1798761599)
Two timestamps sit at the boundary between 2026 and 2027. 1798761600 is the start of 2027 — the half-open upper bound used in most date-range queries. 1798761599 is the last whole second of 2026. This guide explains which to use and shows the conversions in JavaScript, Python, shell, and SQL.
閱讀文章 →Start of 2027 Unix Timestamp: 1798761600 Explained
The Unix timestamp 1798761600 represents 2027-01-01 00:00:00 UTC, the start of 2027 in UTC. This guide shows the conversion, timezone implications, milliseconds form, and how to compute any year-start timestamp.
閱讀文章 →什麼是 UTC 時間?含義、偏移與轉換詳解
UTC(協調世界時)是世界的主要時間標準,也是每個時區的零偏移參考。本指南解釋 UTC 的含義、它是否算作時區、如何讀 24 小時制 UTC,以及如何把 UTC 轉換為 EST、CST、MST、PST 和你自己的本地時間。
閱讀文章 →當前 Unix 時間戳:紀元時鐘、UTC 時間與即時 Unix 時間
當前 Unix 時間戳是此刻自 1970-01-01 00:00:00 UTC 以來的秒數。了解紀元時鐘如何運作、為什麼 UTC 是基準,以及如何在常見語言中取得當前時間戳。
閱讀文章 →在 JavaScript、Python、SQL、Go 中把日期轉成 Epoch
開發者導向的教學,涵蓋如何在 JavaScript、Python、SQL、Go 與 shell 中把日期與時區轉成 Unix epoch。包含 timezone-aware 與 naive 解析、DST gap,以及秒與毫秒的取捨。
閱讀文章 →Epoch 轉換器錯誤：如何避免錯誤的 Unix 時間戳轉換
大多數 epoch 轉換器的 bug 不在數學，而在單位、時區，以及你對輸入所帶的假設。這是一份會產生 1970 年日期和差一小時 bug 的轉換錯誤現場指南，每個都配有能抓出它的那一個驗證步驟。
閱讀文章 →epoch 毫秒轉日期:轉換 13 位時間戳和 long 值
把 epoch 毫秒轉換為可讀日期的指南。涵蓋 13 位時間戳、JavaScript Date、Java long 值、毫秒與秒,以及為什麼錯誤的單位會產生 1970 年或很遙遠的日期。
閱讀文章 →Unix 時間 vs POSIX 時間 vs epoch 時間戳：術語詳解
「epoch 時間戳」「Unix 時間」「POSIX 時間」常被混用，在日常程式碼中它們是同一個數字——自 1970-01-01 UTC 起的秒數。但它們的來歷不同：Unix 時間是慣例，POSIX 時間是正式規範（IEEE Std 1003.1），而「epoch」是指任意參考時刻的通用術語。本指南將每個術語對應到其標準，並指出差異（閏秒、範圍、其他 epoch）真正重要的地方。
閱讀文章 →2026 年初的 Unix 時間戳:1767225600 詳解
Unix 時間戳 1767225600 表示 2026-01-01 00:00:00 UTC,即 UTC 中 2026 年的開始。本指南展示轉換、時區影響、毫秒形式,以及如何計算任意年份的起始時間戳。
閱讀文章 →Unix 時間轉日期 — 將任意 epoch 轉換為可讀日期
Unix 時間戳是自 1970-01-01 UTC 起的秒數。要將其轉換為日期，先以 UTC 解碼，再在任意時區格式化。本指南提供 JavaScript、Python、PHP、shell、SQL（Postgres、MySQL、SQLite、BigQuery）、Excel 和 Google Sheets 中的做法，涵蓋秒與毫秒的陷阱、UTC 與本地、微秒精度、負時間戳以及 2038 年問題。
閱讀文章 →紀元時間詳解:Unix 時間戳零是什麼?
Unix 時間戳 0 是 1970 年 1 月 1 日 00:00:00 UTC。了解為什麼那個日期成為 Unix 紀元、負時間戳代表什麼、紀元的秒/毫秒/微秒有何不同,以及現代系統適用哪些限制。
閱讀文章 →JavaScript Date.now():取得與轉換 Unix 時間戳
聚焦 JavaScript Date.now() 的指南:取得當前 Unix 時間戳、轉換秒與毫秒、把時間戳變成 Date 物件、用 Intl 格式化,並避免常見的解析陷阱。
閱讀文章 →毫秒 vs 秒：如何將 millis 轉換為 Unix timestamp
最常見的時間戳 bug 是在期望秒的地方傳入毫秒,或反過來。學習 10 位與 13 位法則、各語言預設值、對資料庫的影響,以及安全的轉換模式。
閱讀文章 →每個開發者都發布過的 7 個 Unix 時間戳 bug
這些是引發生產事故的時間戳錯誤:悄無聲息的單位不匹配、時區假設、被遺忘的 ×1000、字串儲存、有歧義的解析,以及日光節約時間邊界錯誤。每個 bug 都附帶症狀、根因和實用修復。
閱讀文章 →無需函式庫的 JavaScript 時區正確日期格式化
JavaScript 內建的 Intl.DateTimeFormat 無需 moment.js 或 date-fns 即可處理 IANA 時區格式化。學習顯式 timeZone 選項、對日光節約時間安全的顯示、formatToParts、掛鐘轉換的限制,以及何時 Temporal 或時區函式庫仍然有用。
閱讀文章 →在資料庫中儲存時間戳:DATETIME vs INT vs BIGINT
為時間戳選錯欄位類型會導致時區漂移、2038 年溢位、範圍查詢出錯和混亂的 API 輸出。比較 MySQL 和 PostgreSQL 中的原生 datetime 類型、BIGINT 紀元值和字串。
閱讀文章 →最新文章
關於 Unix 時間戳、JavaScript 中的時區處理、資料庫儲存策略,以及那些悄悄破壞生產系統的時間戳 bug 的實用文章。