POS Bookings: Fix incorrect booking time being displayed due timezone#16718
Open
iamgabrielma wants to merge 8 commits intotrunkfrom
Open
POS Bookings: Fix incorrect booking time being displayed due timezone#16718iamgabrielma wants to merge 8 commits intotrunkfrom
iamgabrielma wants to merge 8 commits intotrunkfrom
Conversation
iamgabrielma
added
type: bug
Collaborator
|
|
…matter The Bookings API stores site-local wall-clock times as UTC timestamps. All booking date operations should use UTC to match this encoding. Centralizes utcTimeZone and utcCalendar so other types can reference them instead of creating their own. Adds formattedShortDate for the date bar display.
The Bookings API stores local times as UTC timestamps and filters against them in UTC. Date queries should use plain UTC midnight-to- midnight boundaries rather than converting from the site timezone. Removes siteTimezone from POSBookingListController and uses POSBookingDateFormatter.utcCalendar for all date arithmetic.
Date bar now uses POSBookingDateFormatter.formattedShortDate instead of an inline formatter with siteTimezone. Calendar view uses the shared utcTimeZone for its DatePicker environment. Both views no longer depend on the siteTimezone environment value.
Remove siteTimezone references and use POSBookingDateFormatter.utcCalendar. Remove the Tokyo timezone test since timezone conversion is no longer relevant - all booking dates use UTC.
Remove locale-dependent assertions and idempotency tests that only verified Apple's formatter behavior. Keep one test per formatter method that checks the output contains the correct UTC values using .contains. Fix incorrect timestamp comments (10:00 UTC, not 9:00).
staskus
approved these changes
Feb 24, 2026
Contributor
staskus
left a comment
staskus
left a comment
There was a problem hiding this comment.
Thanks for the work, @iamgabrielma! Nice that you extracted a formatter separately.
A couple of points I found during testing and fixed right away to save some time. Please check it out and let me know if you see any problems.
Main two changes are:
- Use UTC for date queries as well. Since times are saved in UTC, when showing dates in the date bar and making queries, we should make it in UTC as well. When we create a booking for 1AM UTC, we ignore the timezone. So when we query, we should also ignore it and just request for start-date at 00:00 UTC
- The formatter forced a
USlocale. However, according to requirements the dates still need to presented for a specified region
Small changes:
- I had to adjust tests a little bit to make sure we test only what's necessary and not Apple's formatter logic.
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
3 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.
Closes WOOMOB-2575
Description
When making a test booking I've noticed that while it was made for 11AM, it showed 13PM in the app, and my timezone should fit 16PM, so the booking hours were off at some point.
It seems that the API sends local time disguised as UTC. For booking x (the 11AM Vilnius booking):
This means the Bookings API is encoding the site-local time as a UTC timestamp, not converting to true UTC first (e.g., 11:00 AM Vilnius is sent as epoch for 11:00 UTC, not 09:00 UTC).
More details in p1771921078262749-slack-C070SJRA8DP
Changes
Created
POSBookingDateFormatterthat centralizes all booking time formatting using UTC, so the site-local time is shown correctly regardless of device timezone.Test Steps