Metaobject date time field incorrect output when date different in UTC than local timezone

Topic summary

Core Issue:
Metaobject date-time fields in Shopify display incorrectly when rendered via Liquid if the selected local time results in a different UTC date. Users report the output being 24 hours off or showing incorrect timezone conversions.

Technical Details:

  • Shopify stores date-time values in UTC but displays them in the store’s timezone in the admin UI
  • When selecting times late in the day (e.g., 8pm EDT or later), UTC advances to the next calendar day
  • Liquid rendering shows the UTC date instead of the intended local date
  • Multiple users across different timezones (EDT, AEST, PST) confirm experiencing similar discrepancies (ranging from 8-11 hours off)

Reported Workarounds:

  • Manually adjust timestamps in Liquid using the date filter with timezone offsets
  • Store both UTC and local time in separate metafields
  • Test entries near midnight to verify conversions before deployment
  • Use external time calculation tools to validate UTC conversions

Status:
One user submitted a support ticket to Shopify. The issue remains unresolved with no official response mentioned.

Summarized with AI on October 26. AI used: claude-sonnet-4-5-20250929.

Screenshot 2023-08-22 at 10.38.19.png

In a metaobject I have a date time field. The UI shows the store timezone EDT to the right of the time field. If I select a time in EDT that would mean the UTC date is different (e.g. any time 8pm or after means UTC would be the next day, 23rd of August), then when I render the field in liquid the output is incorrect (it is 24 hours off).

{{ start }} = 2023-08-22T00:00:00Z
{{ start | metafield_tag }} = <time datetime="2023-08-22T00:00:00Z" class="metafield-date_time">Aug 22, 2023, 12:00 am</time>
{{ start | date: "%Y-%m-%dT%H:%M:%S%z" }} = 2023-08-21T20:00:00-0400
{{ start | date: "%s" }} = 1692662400

Expected to output:

2023-08-23T00:00:00Z​
1 Like

There also seems to be a UX issue with the metaobject field, presumably related. Is the UI rendering a different date than is being saved under the hood? https://www.loom.com/share/c58f697d53fc4ad68372e8c3054014a6?sid=d5fc245e-09e0-45f1-be53-356728ec3aa0

Experiencing the same. Although we’re using a DateTime metafield set to AEST and it is rendering 11 hours behind. e.g. 7pm renders as 8am the same day.

I’ve submitted a ticket to Shopify Support

Having the same issue here with ‘date and time’ metafield. The store time zone is PST. The metafield time selected is noted as PST. When linked to a text field as a dynamic source the output is 8 hours ahead (presumably UTC).

Having the same issue with datetime in metaobjects. News about this???

I have come across this issue before when working with date and time fields in Shopify, and it can be confusing at first. The main thing to keep in mind is that Shopify stores metaobject date-time values in UTC, while the admin interface displays them in your store’s timezone.

So if you select a time late in the evening (for example, 8:00 PM EDT), the UTC version is already on the next day. This is why your Liquid output appears to be 24 hours off compared to what you see in the admin.

What has worked for me:

  1. Adjust in Liquid
    Use the date filter with a manual offset to account for your store’s timezone before rendering.
  2. Save both UTC and Local Time
    Create two metafields — one storing the original local time and another storing the UTC time — so you can choose which to display depending on the context.
  3. Test before going live
    Try entering a few times close to midnight in your store’s timezone, then render them in Liquid to confirm the results.

When I was troubleshooting this, I used an external time calculation tool to verify the conversions between local time and UTC. If you work with bookings, shift planning, or any time-sensitive features, I recommend using a quick helper like work time tracker to double-check your offsets and avoid unexpected date changes. It can save you from a lot of head-scratching later.
Regards
M Shozab