Flagging this because it affects delivery-slot accuracy, not just a cosmetic issue. My store’s timezone is not UTC. When I asked the Inbox agent what time it is, it answered with a time exactly 7 hours behind the real local time — a clean UTC offset, not a rounding error.
To be clear, the agent’s cutoff/prep-time logic itself is correct — it’s pulling that from the time slot and cutoff details I have in my store’s FAQ/Knowledge Base content, and it applies that logic properly. The problem is specifically the current-time input it’s using: it’s calculating “are we still within the cutoff” against a UTC clock instead of the store’s actual timezone, so the final answer comes out wrong even though the underlying rule is right.
This is a real risk at the point of ordering — it can tell a customer they’re within a delivery cutoff when they’re not, or the reverse. Given the Inbox agent is a fairly new release (early access), I’d guess this is just something that hasn’t been caught yet rather than an intentional design choice, but wanted to flag it clearly since it’s easy to reproduce.
Has anyone else with a non-UTC store timezone seen this? Would appreciate confirmation on whether the agent is supposed to read the store’s configured timezone (Settings > General > Store details) and this is a bug, or whether it currently defaults to UTC regardless of store settings.