Data Source Time Zone vs. SQL-Level Conversion for Consistent Timestamps

Short answer

Put canonical normalization in the SQL layer and set the WebStorm data source to UTC. Doing both is not redundant — it is the combination that makes the result set immutable: the query controls what the database returns, and the UTC data source setting neutralizes the JDBC driver's display-side conversion so what you see matches the wire value.

The genuinely dangerous configuration is the opposite: an IDE-level offset (or an unset driver default) stacked on top of AT TIME ZONE / CONVERT_TZ in the query. That produces double-conversion, and it is silent — the numbers look plausible, just shifted.

Why the SQL layer should own the conversion

WebStorm's per-data-source time zone setting does not transform data itself; it configures the JDBC driver, which converts TIMESTAMP WITHOUT TIME ZONE values between the server session zone and the configured zone during retrieval. Two consequences follow:

• The setting is client-side and tool-specific. A teammate using psql, DBeaver, or a CI script sees different values unless every client repeats the same configuration.
• The JDBC specification leaves TIMESTAMP WITHOUT TIME ZONE zone handling implementation-defined, so behavior varies across drivers (PostgreSQL, MySQL Connector/J, SQL Server) and across driver versions.

An explicit conversion in the query — for example SELECT created_at AT TIME ZONE 'UTC' FROM ... — travels with the SQL, not with anyone's IDE. That is what makes the result set portable.

Where the driver conversion actually bites

Driver-level conversion applies to zone-less types (TIMESTAMP WITHOUT TIME ZONE, MySQL datetime). Zone-aware types such as PostgreSQL timestamptz carry offset metadata and are typically returned as-is, so they are largely immune. If your schema stores timestamptz normalized to UTC at write time, the cleanest setup is:

1. Store UTC (timestamptz) in the database.
2. Convert explicitly in queries when a non-UTC display is needed.
3. Set the WebStorm data source to UTC so the driver adds no offset of its own.

This also sidesteps a known trap: some drivers (notably MySQL Connector/J 8.0+) fall back to the JVM's default zone unless connectionTimeZone or forceConnectionTimeZoneToSession is set, so "no configuration" is itself a hidden, machine-dependent offset.

Verifying there is no conflicting implicit offset

1. Check the server-side session zone in the same console session: SHOW TIME ZONE; (PostgreSQL) or SELECT @@session.time_zone; (MySQL).
2. In WebStorm's Data Source properties → Advanced tab, review driver properties such as connectionTimeZone, serverTimezone, or forceConnectionTimeZoneToSession, plus the data source's own time zone field.
3. Run a canary query with a known value, e.g. SELECT TIMESTAMP '2024-01-15 12:00:00' AS ts;, and compare the IDE-rendered value against a known-UTC client (psql or mysql with TZ=UTC). Any difference is your implicit offset.
4. If results are ambiguous, enable driver logging (e.g., PGJDBC at FINEST) to inspect the literal timestamp strings on the wire.

Caveats

• If the data source configuration is shared via .idea/dataSources.xml, a UTC change affects the whole team — coordinate or document it.
• ORMs can add a third conversion layer (e.g., Hibernate's hibernate.jdbc.time_zone), independent of the IDE; verify application behavior separately.
• A server-side change such as ALTER DATABASE ... SET timezone shifts the baseline for driver conversion with no code or IDE change.

One missing detail would sharpen this recommendation: which database and driver you use, since the exact property names and defaults differ. The architecture advice above holds regardless.