mirror of
https://github.com/apache/superset.git
synced 2026-05-21 15:55:10 +00:00
cbcfd9599f
Snapshots all four versioned Docusaurus sections at v6.1.0. Built on top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions so the snapshot benefits from: - Auto-gen refresh before snapshotting (database pages from engine spec metadata, API reference from openapi.json, component pages from Storybook stories) — captured at the SHA we cut from rather than whatever happened to be on disk. - Data-import freeze: country list, feature flag table, database diagnostics, and component metadata are copied into snapshot-local `_versioned_data/` dirs so the historical version doesn't silently mutate when the source files change. - Depth-aware import-path rewriter that handles deeply-nested component MDX files referencing `../../../src/` from the snapshot. Versioning behavior: `lastVersion` stays at `current` for every section, so the canonical URLs (`/docs/...`, `/admin-docs/...`, `/developer-docs/...`, `/components/...`) continue to render content from master. The `current` version is consistently labeled "Next" with an `unreleased` banner, and `6.1.0` is a historical pin accessible only via its explicit version segment. Component playground: previously `disabled: true` in versions-config.json, now enabled and versioned. The plugin block in docusaurus.config.ts was already gated only by the `disabled` flag, so no other code changes were needed to bring it back online. The frozen `databases.json` in the snapshot is the canonical 80-database artifact from the latest committed state in master (preserved by the generator's input-hash cache), not a fallback regenerated from a local Flask environment.
51 lines
3.2 KiB
Plaintext
51 lines
3.2 KiB
Plaintext
---
|
|
title: Timezones
|
|
hide_title: true
|
|
sidebar_position: 6
|
|
version: 1
|
|
---
|
|
|
|
# Timezones
|
|
|
|
There are four distinct timezone components which relate to Apache Superset,
|
|
|
|
1. The timezone that the underlying data is encoded in.
|
|
2. The timezone of the database engine.
|
|
3. The timezone of the Apache Superset backend.
|
|
4. The timezone of the Apache Superset client.
|
|
|
|
where if a temporal field (`DATETIME`, `TIME`, `TIMESTAMP`, etc.) does not explicitly define a timezone it defaults to the underlying timezone of the component.
|
|
|
|
To help make the problem somewhat tractable—given that Apache Superset has no control on either how the data is ingested (1) or the timezone of the client (4)—from a consistency standpoint it is highly recommended that both (2) and (3) are configured to use the same timezone with a strong preference given to [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) to ensure temporal fields without an explicit timestamp are not incorrectly coerced into the wrong timezone. Actually Apache Superset currently has implicit assumptions that timestamps are in UTC and thus configuring (3) to a non-UTC timezone could be problematic.
|
|
|
|
To strive for data consistency (regardless of the timezone of the client) the Apache Superset backend tries to ensure that any timestamp sent to the client has an explicit (or semi-explicit as in the case with [Epoch time](https://en.wikipedia.org/wiki/Unix_time) which is always in reference to UTC) timezone encoded within.
|
|
|
|
The challenge however lies with the slew of [database engines](/user-docs/databases#installing-drivers-in-docker) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timestamp are serialized to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone.
|
|
|
|
For example the following is a comparison of MySQL and Presto,
|
|
|
|
```python
|
|
import pandas as pd
|
|
from sqlalchemy import create_engine
|
|
|
|
pd.read_sql_query(
|
|
sql="SELECT TIMESTAMP('2022-01-01 00:00:00') AS ts",
|
|
con=create_engine("mysql://root@localhost:3360"),
|
|
).to_json()
|
|
|
|
pd.read_sql_query(
|
|
sql="SELECT TIMESTAMP '2022-01-01 00:00:00' AS ts",
|
|
con=create_engine("presto://localhost:8080"),
|
|
).to_json()
|
|
```
|
|
|
|
which outputs `{"ts":{"0":1640995200000}}` (which infers the UTC timezone per the Epoch time definition) and `{"ts":{"0":"2022-01-01 00:00:00.000"}}` (without an explicit timezone) respectively and thus are treated differently in JavaScript:
|
|
|
|
```js
|
|
new Date(1640995200000)
|
|
> Sat Jan 01 2022 13:00:00 GMT+1300 (New Zealand Daylight Time)
|
|
|
|
new Date("2022-01-01 00:00:00.000")
|
|
> Sat Jan 01 2022 00:00:00 GMT+1300 (New Zealand Daylight Time)
|
|
```
|