How Time Zone Settings Affect Timestamp Data

Last updated: July 14, 2026

Tier Deployment
Launch     Grow    Enterprise Cloud     On-Prem

IMPORTANT:

This topic is intended as assistance for understanding and configuring time zone behavior for imported TIMESTAMP and TIMESTAMP WITH TIME ZONE data. It does not describe an officially supported Sisense feature. Time zone adjustments are not officially supported by Sisense. The configuration options and query patterns described below may help you achieve the result you expect for a given data source, but Sisense cannot guarantee that they will behave identically across all supported connectors and drivers. Always verify the actual values returned after a full ElastiCube Build (or in a Live query) against your own source data before relying on this behavior.

When a source database column is typed as TIMESTAMP WITH TIME ZONE (also called TIMESTAMPTZ) and your custom query uses functions that convert or specify a time zone, the value stored in Sisense can differ from what you see in a database client such as DBeaver, and can differ again between the query preview and the value after a Build. This topic explains why, and how the TZ deployment setting and the OriginalDBTimeInEC parameter affect the result.

Background: TIMESTAMP vs. TIMESTAMP WITH TIME ZONE

  • TIMESTAMP (without time zone) is a "wall-clock" value with no time zone metadata attached. It is not subject to any time zone conversion by Sisense or by the source database's driver.
  • TIMESTAMP WITH TIME ZONE is stored internally by the source database in UTC. When a client (such as the JDBC driver Sisense uses to query the database) reads that value, the database driver converts it to the client's configured time zone before returning it.

In a Sisense on-Kubernetes deployment, the client time zone used for this conversion is controlled by the TZ variable in the global-configuration ConfigMap:

kubectl -n sisense edit cm global-configuration

All pods must be restarted for a change to this value to take effect (kubectl -n sisense delete pods --all).

The OriginalDBTimeInEC Parameter

OriginalDBTimeInEC is a Base Configuration parameter that controls whether Dates and Datetimes are altered during import into an ElastiCube. It is enabled by default.

To view or change this setting:

  1. Navigate to Admin > Server & Hardware > System Management > Configuration.
  2. Click the Sisense logo five times to display Advanced Options.
  3. Select Base Configuration, and expand OriginalDBTimeInEC.
  4. Enable or disable OriginalDBTimeInEC.value as needed, then save.

Note:

You must fully rebuild each ElastiCube for a change to this parameter to take effect.

Retrieving TIMESTAMP WITH TIME ZONE Data in a Specific Time Zone

To import TIMESTAMP WITH TIME ZONE data so that it is stored as a plain TIMESTAMP value representing a specific time zone, the configuration you need depends on the TZ ConfigMap setting.

When TZ Is Set to a Non-UTC Time Zone

  • In Configuration Manager > Base Configuration, ensure OriginalDBTimeInEC.value is Enabled (the default).
  • In the import Importing Data with Custom Queries, use a time zone conversion function appropriate to your data source (for example, Redshift's CONVERT_TIMEZONE(), or PostgreSQL's TIMEZONE()) to convert the TIMESTAMP WITH TIME ZONE value into a TIMESTAMP expressed in the desired time zone.

Important:

The values shown when parsing or previewing the Table Query will differ from the values stored after a Build. During preview, the TIMESTAMP WITH TIME ZONE value is first converted to the time zone specified by TZ, and then the result of your conversion function is treated as if that already-converted time were UTC and is converted again. This means the preview does not show the correct value. Always verify the actual result after completing a Build.

When TZ Is Set to UTC

  • In the import Table Query, use a time zone conversion function to convert the TIMESTAMP WITH TIME ZONE value into a TIMESTAMP expressed in the desired time zone, as above.
  • No additional OriginalDBTimeInEC configuration is required, and the preview values will match the values stored after a Build.

Worked Example (Redshift)

The following query converts a UTC timestamp to Asia/Tokyo time and then casts the result to TIMESTAMP WITH TIME ZONE:

CAST(CONVERT_TIMEZONE('UTC','Asia/Tokyo','2025-07-13 20:00:00') AS TIMESTAMP WITH TIME ZONE)

This query is processed in two steps, and understanding each step explains results that otherwise look inconsistent:

  1. Time zone conversion (CONVERT_TIMEZONE): Converts 2025-07-13 20:00:00 from UTC to Asia/Tokyo (JST, UTC+9), producing 2025-07-14 05:00:00. In Redshift, CONVERT_TIMEZONE returns a plain TIMESTAMP (no time zone metadata) — it is only the wall-clock time, 5:00 AM on July 14.

  2. Explicit cast (CAST ... AS TIMESTAMP WITH TIME ZONE): Takes that time-zone-less value and converts it to TIMESTAMP WITH TIME ZONE. When Redshift casts a TIMESTAMP to TIMESTAMP WITH TIME ZONE, it appends the time zone offset of the current Redshift session, which defaults to UTC:

    • If the session's time zone is UTC (the default), the result is 2025-07-14 05:00:00+00 — the 5:00 AM wall-clock value is treated as if it were already UTC.
    • If the session's time zone is set to Asia/Tokyo, the result is 2025-07-14 05:00:00+09 — the JST offset is correctly retained.

In other words, the "correct" result depends on what time zone the query session itself is running in, independently of the TZ ConfigMap and OriginalDBTimeInEC settings covered above. Once the session time zone is accounted for, this query produces consistent results in both ElastiCube and Live models.

This Behavior Is Not Specific to Redshift

The same pattern — a source-side TIMESTAMP WITH TIME ZONE type, a client/session time zone applied by the driver, and a conversion function used in a custom query — has also been observed in PostgreSQL, and is likely to apply to other relational sources that support a TIMESTAMP WITH TIME ZONE-equivalent type. The exact function names and default session behavior vary by database and driver (for example, PostgreSQL's TIMEZONE() function returns a timestamp with slightly different behavior than Redshift's CONVERT_TIMEZONE()), so treat the steps above as a pattern to test against your own source rather than as a universal formula. See the caveat at the top of this topic.

This applies to both ElastiCube and Live models, since in both cases the time zone conversion is performed by the source database and its driver rather than by Sisense.