fix: use utcFormat for temporal axis label comparisons#161
Merged
cpsievert merged 2 commits intoposit-dev:mainfrom Mar 2, 2026
Merged
fix: use utcFormat for temporal axis label comparisons#161cpsievert merged 2 commits intoposit-dev:mainfrom
cpsievert merged 2 commits intoposit-dev:mainfrom
Conversation
The Vega-Lite labelExpr for temporal scales (date, datetime, time) was using timeFormat() to compare axis tick values against ISO date keys from the RENAMING clause. timeFormat formats in the browser's local timezone, but ggsql writes all temporal data as UTC ISO strings (e.g., "2024-01-01" represents midnight UTC). In non-UTC timezones, this causes every label comparison to fail. For example, in US Central Time (UTC-6), timeFormat formats "2024-01-01" (midnight UTC) as "2023-12-31" (6 PM local), so the comparison against the key "2024-01-01" never matches. The labelExpr falls through to datum.label (Vega-Lite's default formatter), which shows time-of-day labels like "06 PM" / "07 PM" instead of the expected date labels. The fix is to use utcFormat(), which formats in UTC and matches the ISO date keys that ggsql generates. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
cpsievert
force-pushed
the
fix/utc-format-temporal-labels
branch
from
aea16b6 to
e994810
Compare
Collaborator
|
once you reformat I'm happy to merge |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Date axis labels show nonsensical time-of-day values like "06 PM" / "07 PM" instead of formatted dates when using
RENAMINGon temporal scales (e.g.,SCALE x VIA date RENAMING * => '{:time %b %Y}').The x-axis should show month/year labels like "Jan 2024", "Feb 2024", etc. — instead it shows "06 PM" / "07 PM" alternating (the alternation is caused by DST shifts).
Root Cause
The Vega-Lite
labelExprgenerated for temporal scales usedtimeFormat(datum.value, '%Y-%m-%d')to compare axis tick values against ISO date keys from theRENAMINGclause. The problem is thattimeFormatformats timestamps in the browser's local timezone, while ggsql writes all temporal data as UTC ISO strings.In any non-UTC timezone, every comparison silently fails:
"2024-01-01"→ midnight UTCtimeFormat(datum.value, '%Y-%m-%d')"2024-01-01""2023-12-31"(6 PM local = previous day)"2024-01-01"When all comparisons fail, the
labelExprfalls through todatum.label(Vega-Lite's default temporal formatter). Since the tick values are midnight UTC — which translates to ~6 PM local time — Vega-Lite auto-formats them as time-of-day labels. The "06 PM" / "07 PM" alternation comes from DST: winter months are UTC-6, summer months are UTC-5.Fix
One-line change:
timeFormat→utcFormatinbuild_label_expr(). TheutcFormatfunction formats in UTC, matching the ISO date keys that ggsql generates.Test Plan
build_label_exprcovering temporal (utcFormat), non-temporal (datum.label), empty mappings (fallback), and null suppression