NocoBase timestamp shifts explained: MySQL stores no timezone, PostgreSQL does

Developers using NocoBase have repeatedly reported datetime values appearing shifted by several hours, a pattern matching their local UTC offset. Testing NocoBase 2.x against both PostgreSQL 16 and MySQL 8.4 revealed the root cause: MySQL's DATETIME type stores only a wall-clock value with no timezone offset, while PostgreSQL's timestamptz preserves the offset as part of the stored data. Because MySQL lacks offset storage, NocoBase must interpret stored times using the server's TZ setting on every read and write, meaning any change to that setting silently shifts the meaning of all existing timestamps. On PostgreSQL, the same timezone-change experiment produced no shift, since the offset is already encoded in the stored value. The practical guidance is to set the server timezone explicitly from day one, never change it, and keep it consistent across all environments — or choose PostgreSQL to avoid the issue structurally.