DateField off by 1 day issues

To remove our code from the scenario I’ve hardcoded the value to the date field as “1997-04-12”.

Expected: Renders 1997-04-12
Actual: Renders 1997-04-11

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).

1 Like

You can use:

  1. Use Date in ISO format with no timezone parsing
  2. If you must use JS Date (not recommended for just dates), use toISOString()

Hi Robert,

  1. This is what we are doing when using 1997-04-12?
  2. We’re not using a JS Date, the example above is a string literal set as the value. This was done to rule out any funky business on our side.

Have you been able to get it done?

Hey @SFLL ,

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.

1 Like

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 :laughing:)

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.

1 Like

Hi Kyle,

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.

Thanks

Thanks for following up. I’m still looking in to the best options here. I’ll be sure to reply once I have that!

1 Like