While I was building out the price scheduling feature for Metra, I needed users to pick a date and a time. The date part was easy. Shopify Polaris web components ships <s-date-field> and it works great. Then I went looking for the equivalent time component, and of course, there isn’t one.
There’s <s-time-picker> and <s-time-field>, but those are POS UI Extensions only. If you’re building an Admin-facing embedded app using App Home / App Bridge web components, you get nothing. A few other developers have run into the same wall and there’s an open request to add it, but for now it doesn’t exist.
My first instinct was to reach for a plain <input type="time">. It works, but it looks wrong sitting inside a Polaris UI. The browser renders it however it wants and it sticks out. I wanted something that felt native to the design system.
So I built a small component using three <s-select> dropdowns: hour, minute, and AM/PM. It’s not complicated, but there are a few things worth knowing before you try it yourself.
The core problem: 12-hour display, 24-hour storage
The UI should show a standard 12-hour clock (1–12 + AM/PM) because that’s what most users expect. But internally you want to store time as "HH:mm" in 24-hour format. In my experience, it’s easier to work with in code, easier to send to a backend, and easier to validate against Date.now().
That means you need two small conversion functions:
The edge cases to get right: 12 AM is 00:00, and 12 PM is 12:00. I have to handle these explicitly to get the right time to show.
The component
A few things I’d flag:
labelAccessibilityVisibility="exclusive" hides the individual dropdown labels visually but keeps them in the accessibility tree. Without this, you’d end up with three visible labels (“Hour”, “Minute”, “AM/PM”) stacked under whatever parent label you’ve already set.
idPrefix matters if you have more than one time picker on the page. For example, a “start time” and an “end time.” Pass a unique prefix to each instance so the name attributes don’t collide.
e.currentTarget?.value ?? e.target?.value: I’ve seen Polaris web component events behave slightly differently across versions, so the fallback is worth keeping.
Dropping it into a form
In practice it sits next to <s-date-field> and just works:
I keep them as separate state values ("YYYY-MM-DD" and "HH:mm") and combine them server-side with the user’s timezone:
For validation, combining them into a timestamp makes it straightforward to check whether the selected time is in the future:
That’s the whole thing. It’s a bit more code than I’d like, and I’m hoping Shopify eventually ships a native time component for Apps the way they have for POS. Until then, this works well enough that I haven’t thought about it since.
Building Shopify apps? Metra is an price scheduler automation tool for Shopify merchants that handles bulk price changes, scheduled in advance, with automatic revert. Contact us to learn more!