Timezone issue with GROK now() function when filtering by datetime in Sanity editor
You're experiencing a timezone offset issue with GROQ's now() function. This is a common problem, and here's what's actually happening:
The Root Cause:
The now() function returns the current UTC timestamp as a string in RFC3339 format (like 2021-08-19T15:51:24.846513Z). When you set 8 AM in the Studio datetime picker, you're likely setting it in your local timezone, but the stored value gets converted to UTC. The 1-hour difference you're seeing suggests your local timezone is UTC+1.
The Solution:
You need to wrap your stored publicationDate field in the dateTime() function to ensure proper comparison:
*[_type == 'quiz' && dateTime(publicationDate) <= now()]Or for extra clarity, wrap both sides:
*[_type == 'quiz' && dateTime(publicationDate) <= dateTime(now())]Why This Works:
The dateTime() function converts datetime strings into comparable datetime objects. When datetime fields are stored in Sanity, they're stored as strings in RFC3339 format. The dateTime() function ensures these strings are properly parsed for comparison operations.
Since now() already returns a UTC timestamp string, the critical part is converting your stored publicationDate field with dateTime() so both values are being compared as proper datetime objects rather than plain strings.
Important Note:
The now() function always returns UTC time, which is expected behavior. When you set "8 AM" in the Studio datetime picker, make sure you're aware of what timezone that represents. If you're in UTC+1 (like CET), setting 8 AM local time means the stored UTC value is actually 7 AM UTC, which explains why your query only returns results at 9 AM local time (8 AM UTC).
Double-check that your publicationDate field is using the datetime schema type in your Studio configuration to ensure proper datetime formatting and storage.
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.