mirror of
https://github.com/apache/superset.git
synced 2026-05-22 00:05:15 +00:00
4266d36cf4
Snapshots all four versioned Docusaurus sections at v6.1.0, cut from master after the version-cutting tooling (#39837) and broken-internal- links fixes (#40102) landed. Captures fresh auto-generated content and freezes data dependencies so the historical snapshot stays correct. 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. Snapshot includes: - All MDX content for the four sections. - Auto-gen captured fresh: 74 database pages (engine spec metadata), ~1,800 API reference files (openapi.json), 59 component pages (Storybook stories). - Data imports frozen at cut time into snapshot-local _versioned_data/ dirs: versioned_docs/version-6.1.0/_versioned_data/src/data/databases.json (canonical 80-database diagnostics from master, preserved by the generator's input-hash cache) admin_docs_versioned_docs/version-6.1.0/_versioned_data/data/countries.json admin_docs_versioned_docs/version-6.1.0/_versioned_data/static/feature-flags.json developer_docs_versioned_docs/version-6.1.0/_versioned_data/static/data/components.json - Import paths in deeply-nested files rewritten so they still resolve from one directory deeper inside the snapshot. Verified via full yarn build: exit 0, no broken links surfaced by onBrokenLinks: throw. Anchor warnings present are pre-existing on master (community#superset-community-calendar) and unrelated.
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)
|
|
```
|