Note I myself am located in BST/GMT+1 but the customer who raised this issue was located in GMT-5. They reported seeing issues with dates off by one or two.
At the time I replicated this issue I switched my test device to GMT-5 and was running the above test at what would be classed as 6:22am, despite this the date was still rendered minus 1 day.
Finally I’ve had other engineers try to replicate this on demand and not been successful, so we’re not sure what else could be going on. Obviously some form of time element is being considered but this is either not clear or documented.
Understanding here is that this is just a date field and that the time would have no impact (we don’t have a time element for example as this relates to a users birthday).
Since your customer is in GMT-5, that’s also most likely the timezone for the shop. When you’re not specifying the timezone, it’s being set as UTC time, and then converted to the timezone of the shop.
This also explains why changing your test device isn’t affecting anything.
To confirm, if you query the date on the API, it will likely be 1997-04-11T19:00:00-05:00
Ah thank you, this explains why depending on some tests we were seeing different results. Assumption here as the docs are not clear was that it would use the device settings, not the store. Generally I’d guess these would be aligned in real life anyway so probably not a huge issue.
Having used 1997-04-11T19:00:00-05:00 I can see this work with a matching store using GMT as the configured timezone.
Just to confirm then, despite this being a date we should always include the current timezone of the store in use aka datetime. As long as we pull this from the store settings not the device this should then align in all scenarios.
@KyleG-Shopify So essentially in order to get from a pure date value, e.g. 1997-04-12 and use it as the input to / interact with the DateField component, you need to know the store’s timezone setting?
It seems odd that the DateField component would both parse a date assuming one timezone and then convert it into another?
Is there any way to get the store timezone through the extension api’s? Seeing as it seems to be a necessary piece of information for working with this component
Hey @atreidesend , that’s a good call out. Above I was looking more generally as typically programmatic/api requests that don’t specify a timezone will be processed as UTC.
This is common occurrence in other areas as well. For example reporting in a store admin will use the stores timezone, but if building reports and getting the data from the API, you can see discrepancies if not taking this in to account.
I’ll dig in some more to find out specifically the best way to handle this with the DateField component.
Appreciate it! Our use case is capturing a customer’s birthdate for loyalty / reward purposes. So we’re actually looking to essentially treat the value as “just a date” (people don’t really care what timezone their birthday was in )
In the meantime, we can transpose it to midnight-store-local-timezone ahead of time in order to work around this, but in the long run it would be interesting to have a way to interact with this component in either a “just a date” fashion, or at least in a “I don’t need to know what timezone you’re thinking in ahead of time” kind of way.
It seems that might be useful for lots of more ‘local’ use cases, esp with POS, where it seems the store location may not even be in the same timezone as the ecommerce store anyways.
Is there any update on the best way to handle this.
We’re very much keen to explore the “it’s just a date”/“we don’t need to know the timezone” as @atreidesend mentioned this makes working with this component quite fiddly.
@SFLL
Unfortunately, we don’t have an immediate workaround until we implement the option to select between date-only and date-time values.
However, could you try adjusting the input value to explicitly specify midnight UTC, like so:
const adjustedValue = `${value}T00:00:00Z`;
Why this works:
Appending "T00:00:00Z" explicitly sets the time to midnight UTC, preventing timezone shifts.
This ensures that when the date is parsed by new Date(), it will always represent the correct date regardless of the user’s timezone.
Example:
If your original date is "1997-04-12", you’d pass in "1997-04-12T00:00:00Z" instead. This should reliably render the correct date across all user timezones.
)