資料載入中

胡言亂語

PostgreSQL對應MySQL注意事項,時間與日期格式是最容易踩雷的地方之一

從 MySQL 轉到 PostgreSQL(或雙軌並行)時,時間與日期格式是最容易踩雷的地方之一。雖然兩者都支援 SQL 標準,但底層邏輯、預設行為和函數名稱有很大的不同。

以下最關鍵的注意事項與對應關係:

1. 資料型態的對應與隱含陷阱

MySQL 和 PostgreSQL 在時間型態的命名與「時區自動轉換」的處理上有所差異:

MySQL 的 TIMESTAMP:會受到 MySQL 伺服器時區(time_zone)的影響。寫入時轉為 UTC 儲存,讀取時轉回當前時區。範圍只到 2038 年(32位元限制)。

PostgreSQL 的 TIMESTAMP:完全不管時區。如果您把 MySQL 的 TIMESTAMP 直接轉成 PostgreSQL 的 TIMESTAMP,時區轉換邏輯會直接消失!

解決方案:在 PostgreSQL 中,請一律使用 TIMESTAMPTZ 來對應需要處理時區的時間欄位。PostgreSQL 的 TIMESTAMPTZ 內部也是存 UTC,且支援到西元 292278 年。

2. 常用時間函數與語法對應

MySQL 的許多便利函數在 PostgreSQL 中並不適用,必須改用 SQL 標準語法:

取得當前時間MySQL: NOW(), CURRENT_TIMESTAMP(), SYSDATE()

PostgreSQL: NOW() 或 CURRENT_TIMESTAMP(注意:PostgreSQL 沒有 SYSDATE())。

  • 時間與日期格式轉換的挑戰
  • MySQL 與 PostgreSQL 的時區處理差異
  • 資料型態轉換過程中的隱含陷阱
  • 使用 TIMESTAMPTZ 處理時區的最佳實踐
  • 常用時間函數在不同資料庫的對應
  • 故事
https://innstory.com/story-PostgreSQL對應MySQL注意事項時間與日期格式是最容易踩雷的地方之一-7220

上一篇
 如何使用mailtestercom判斷SPF/DKIM是否正確並評估你的郵件評分

發表留言

作者簡介

離不開電腦的宅男


推薦閱讀

作者其他相關類別故事

PHP Caching Headers

PHP Caching He…

Mark Chang 8 年又 16 天 2K

最近測試平台系統執行速度,老實說測試的有點無力~ 總覺得能做的可以做的都做了,但速度就是快不了~...

Linux下查看版本號指令

Linux下查看版本號指令

Mark Chang 7 年又 298 天 1.9K

其他指令查詢方式 以上紀錄~

點選檔案下載卻直接執行開啟

點選檔案下載卻直接執行開啟

Mark Chang 4 年又 351 天 1.5K

遇到一個情況。 使用者開啟瀏覽器點選某個連結檔案時,不會執行下載而是直接開啟檔案。 原本如果只是圖片...