fix(ui5-dynamic-date-range): correct off-by-one-day date shift in negative UTC offsets - #14017
Open
unazko wants to merge 5 commits into
Open
fix(ui5-dynamic-date-range): correct off-by-one-day date shift in negative UTC offsets#14017unazko wants to merge 5 commits into
unazko wants to merge 5 commits into
Conversation
…ative UTC offsets Issue: When selecting dates using the DATE or DATERANGE options, the resolved values were shifted one day earlier than what the user selected in the calendar. This occurred in browsers running in negative UTC-offset timezones (e.g. America/Los_Angeles, America/Monterrey). The calendar fires selectedDates as Unix timestamps in seconds representing UTC midnight. Both SingleDate and DateRange converted these directly via new Date(ts * 1000) / UI5Date.getInstance(ts * 1000), producing a Date at UTC midnight. In a GMT-6 environment, that instant is the previous day at 18:00 local time. The subsequent setHours(0, 0, 0, 0) call in toDates() then locked in the wrong local day. Solution: Replace the raw timestamp-to-Date conversion in handleSelectionChange with CalendarDate.fromTimestamp(ts * 1000).toLocalJSDate(). CalendarDate is a date-only abstraction that stores the day in UTC internally; toLocalJSDate() re-applies the UTC year/month/date as local date fields, ensuring the resulting Date always represents the correct calendar day at local midnight regardless of timezone offset. This mirrors the same pattern already used in CalendarDate internally. Fixes: #14005
unazko
temporarily deployed
to
netlify-preview
September 2, 2026 08:00 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
unazko
temporarily deployed
to
netlify-preview
September 2, 2026 08:05 — with
GitHub Actions
Inactive
GitHub Actions
Inactive
|
🚀 Deployed on https://pr-14017--ui5-webcomponents-preview.netlify.app |
unazko
temporarily deployed
to
netlify-preview
September 2, 2026 08:32 — with
GitHub Actions
Inactive
GitHub Actions
Inactive
didip1000
self-requested a review
September 3, 2026 06:35
didip1000
reviewed
Sep 4, 2026
didip1000
left a comment
didip1000
left a comment
Contributor
There was a problem hiding this comment.
I think SingleDate would also need to be fixed
Contributor
Author
Actually the SingleDate option was already fixed, but you have a good point. There are two more options that have the same timezone related issue. |
…ative UTC offsets Issue: When selecting dates using the DATE, DATERANGE, FROMDATETIME or TODATETIME options, the returned dates were one day earlier than what the user picked in the calendar. This only affected users in timezones behind UTC (e.g. Americas), where the internal calendar timestamp was being interpreted as the previous local day. Solution: The timestamp coming from the calendar represents a specific calendar day in UTC. Instead of converting it directly to a JavaScript Date (which shifts it into local time), we now use the existing CalendarDate abstraction to extract the correct day and produce a local Date that always matches what the user selected, regardless of timezone. The conversion is extracted into a shared calendarTimestampToLocalDate helper in toDates.ts so all affected options use a single consistent implementation. A unit test for calendarTimestampToLocalDate is included, validating that the local date components of the result always match the UTC date of the calendar timestamp. Note: the test is most meaningful in negative UTC-offset environments; to verify locally run the calendar selection tests with TZ=America/Los_Angeles. Fixes: #14005
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.
Issue:
When selecting dates using the DATE, DATERANGE, FROMDATETIME or TODATETIME
options, the returned dates were one day earlier than what the user picked in the
calendar. This only affected users in timezones behind UTC (e.g. Americas), where
the internal calendar timestamp was being interpreted as the previous local day.
Solution:
The timestamp coming from the calendar represents a specific calendar
day in UTC. Instead of converting it directly to a JavaScript Date (which shifts
it into local time), we now use the existing CalendarDate abstraction to extract
the correct day and produce a local Date that always matches what the user
selected, regardless of timezone. The conversion is extracted into a shared
calendarTimestampToLocalDate helper in toDates.ts so all affected options use
a single consistent implementation.
A unit test for calendarTimestampToLocalDate is included, validating that the
local date components of the result always match the UTC date of the calendar
timestamp. Note: the test is most meaningful in negative UTC-offset environments;
to verify locally run the calendar selection tests with TZ=America/Los_Angeles.
Fixes: #14005