[coverage] Conformance findings: COMPLEX-016
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 56/100
Piste de recherche
Start with the coverage PR diff under tests/ and inspect TestNestedTimestampNtzKeepsItsWallClockInArrayMapAndStruct to see how the failure is reproduced. Trace how the SEA/kernel backend renders nested ARRAY, MAP, and STRUCT values and handles each child field's time zone. Done means the test passes in a non-UTC session while nested NTZ values retain 09:15:00.123456 and the zoned timestamp remains 13:15:00.123456Z.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Summary
Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-go) is fixed, then flips green as a tripwire.
Findings
- COMPLEX-016 [sea]: SEA/kernel backend applies the session-zone conversion to nested TIMESTAMP_NTZ leaves: an NTZ leaf inside ARRAY/MAP/STRUCT renders 05:15:00.123456 instead of the literal's 09:15:00.123456 under America/New_York, while the top-level NTZ column is correct — the container walk forwards one session location to every child instead of resolving the render location per child field
- failing test:
TestNestedTimestampNtzKeepsItsWallClockInArrayMapAndStruct(see the coverage PR diff undertests/)
- failing test:
- COMPLEX-016: SEA/kernel backend applies the session-zone conversion to nested TIMESTAMP_NTZ leaves: under America/New_York an NTZ leaf inside ARRAY/MAP/STRUCT renders 05:15:00.123456 instead of the literal's 09:15:00.123456, while the top-level NTZ column is rendered correctly — the container walk forwards one session location to every child instead of resolving the render location per child field
Reproduce & Expected
COMPLEX-016 — Verify that under a NON-UTC session time zone a TIMESTAMP_NTZ leaf nested inside an ARRAY element, a MAP value, a STRUCT field, and a STRUCT inside a STRUCT keeps the exact wall clock the literal car…
Reproduce:
- Set the session time zone through whichever surface the driver exposes -- a
session parameter on connect (e.g. atimezonesession param) or, where no
such option exists,SET TIME ZONE 'America/New_York'on the same session
before the test query. A NON-UTC zone is REQUIRED: under a UTC session the
shifted and unshifted NTZ renderings coincide and the case proves nothing.
Expected (per the shared spec):
- result has exactly 1 row(s)
- full assertion contract:
result:
- row_count: 1
- timestamp_wall_clock:
path: ntz_array[0]
equals: '2024-06-15 09:15:00.123456'
- timestamp_wall_clock:
path: ntz_map['a']
equals: '2024-06-15 09:15:00.123456'
- timestamp_wall_clock:
path: ts_struct.ntz
equals: '2024-06-15 09:15:00.123456'
- timestamp_wall_clock:
path: ts_struct.inner.ntz
equals: '2024-06-15 09:15:00.123456'
- timestamp_instant:
path: ts_struct.zoned
equals: '2024-06-15T13:15:00.123456Z'
- struct_field:
column: ts_struct
field: label
equals: pt
Context
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-go/pull/510 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
- Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1897
- Langage dominant
- Go
- Étoiles
- 53
- Forks
- 69
- Merge moyen
- 2 j 12 h
- PR mergées (30 j)
- 16
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de databricks/databricks-sql-go
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
databricks/databricks-sql-go#494 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 1-2 jours Accessibilité débutants 52/100
databricks/databricks-sql-go#521 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 49/100
databricks/databricks-sql-go#517 ·
Les mainteneurs répondent en général sous 1 jour
-
TIME (time64[ns]) type unhandledOuvertebug engineer-bot
Difficulté 3/5 1-2 jours Accessibilité débutants 67/100
databricks/databricks-sql-go#505 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
databricks/databricks-sql-go#504 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de databricks/databricks-sql-go
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
apache/arrow-swift#209 ·
Les mainteneurs répondent en général sous 1 jour
-
orchestrator: NFS-cache "cache path is not set" WARN logged on every build/launch instead of oncePeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 1-3 heures Accessibilité débutants 65/100
influxdata/telegraf#20031 ·
Les mainteneurs répondent en général sous 1 jour
-
pkg/registry/file no longer builds for GOOS=windows: unguarded syscall.Stat_t in qualified_resource_migration.goPeut-être pris @AnshulPatil2005 l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
OneBusAway/maglev#1914 ·
Les mainteneurs répondent en général sous 2 jours