Sequelize v6 DATE type timezone handling shift: impact on storage and retrieval

Goal: Determine whether Sequelize should automatically apply the instance‑level timezone to DATE values when the underlying dialect stores them in a timezone‑aware column type (e.g., PostgreSQL timestamptz) or leave the values unchanged, ensuring a predictable mapping between model definitions and database storage across MySQL, SQLite and PostgreSQL.

Constraints: The change must preserve backward compatibility for existing applications that rely on the current v6 behavior, avoid silent data corruption when the timezone option is modified after sync, and respect the differing column types each dialect uses for DATE. The unresolved decision centers on whether automatic conversion should be opt‑in, opt‑out, or the default, and how migrations should handle pre‑existing data.

Specific questions:

• Should Sequelize apply the instance timezone to DATE values for PostgreSQL timestamptz columns, or store them as‑is?
• If the behavior changes, what migration strategy should be provided to adjust existing DATE values without loss of information?
• Can a configuration flag be introduced to let users choose between automatic conversion and preserving the raw JavaScript Date?