feat(analytics): datetime date-bucket drill uses reference-tz midnight instants (#1752 follow-up)#3272
Merged
Conversation
…t instants (#1752 follow-up) A `datetime` date dimension bucketed under a non-UTC reference tz previously fell back to a superset drill (its bucket boundary is that tz's midnight instant, which YYYY-MM-DD calendar bounds can't express). Emit those instants instead, closing the last gap from the initial #1752 change. - core: add `zonedDateStartToUtcMs(ymd, tz)` — the UTC instant a calendar day begins in a reference tz (inverse of calendarPartsInTz). DST-safe via Intl with a two-pass offset resolution; unset/UTC/invalid zone → plain UTC midnight. - service-analytics: emit drillRanges bounds by field temporal type (ADR-0053) — datetime → ISO instant at the tz's midnight (any tz, incl. DST); date → YYYY-MM-DD calendar (tz-naive). Unknown type stays UTC-only. objectui needs no change — the client already forwards arbitrary bound values into the drill filter and the filter[field][gte|lt] URL. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RCXBnmMQTwjmFkjtpEe11f
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
Contributor
📓 Docs Drift CheckThis PR changes 2 package(s): 26 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
os-zhuang
marked this pull request as ready for review
July 19, 2026 12:10
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.
Why
Follow-up to #3256 (which landed #1752). That change deliberately left one gap: a
datetimedate dimension bucketed under a non-UTC reference timezone fell back to a superset drill. Adatetimebucket's boundary is that timezone's midnight instant, which theYYYY-MM-DDcalendar bounds couldn't express — so rather than emit a wrong (tz-offset) bound, it emitted none. This closes that gap.What
@objectstack/core— addzonedDateStartToUtcMs(ymd, tz): the UTC instant at which calendar dayymdbegins in reference timezonetz(the inverse ofcalendarPartsInTz). DST-safe — the offset is read from the platform tz database viaIntl.DateTimeFormat, with a two-pass resolution for the rare offset-boundary case; an unset /'UTC'/ invalid zone returns plain UTC midnight.@objectstack/service-analytics— emitdrillRangesbounds per the field's temporal type (ADR-0053):datetime→ ISO instant bounds at the reference tz's midnight (works under any tz, including DST);date→YYYY-MM-DDcalendar bounds (tz-naive, exact under any tz);No objectui change — the client already forwards whatever bound values the server sends into the drill filter and the
filter[field][gte|lt]URL contract, so ISO-instant bounds flow through unchanged.Testing
zonedDateStartToUtcMs(9 cases): fixed offset (Asia/Shanghai +08), DST zone summer/winter (America/New_York EDT/EST), DST-transition days, unknown zone → UTC, unparseable → NaN, plus a round-trip that proves the instant lands exactly on the day boundary in the zone.datetimedim underAmerica/New_Yorknow drills2026-06-01T04:00:00.000Z → 2026-07-01T04:00:00.000Z(EDT midnight = 04:00 UTC).@objectstack/service-analytics170/170,@objectstack/objectqldate-bucket-range 49/49 (regression), coredatetime9/9; type-check clean (DTS build).🤖 Generated with Claude Code
https://claude.ai/code/session_01RCXBnmMQTwjmFkjtpEe11f
Generated by Claude Code