Handling timezones in Sanity.io richDate fields

9 replies
Last updated: Oct 20, 2021
Hello Sanity Community. I have users enter data in a richDate field. The issue is that users in different timezones enter data so the times are all off for users. Is it possible to specify a timezone in which the data is entered? This timezone also has PDT and PST…
AI Update

I understand your timezone challenge with users entering data from different locations! There are a couple of good solutions for handling timezone-specific datetime entry in Sanity Studio.

Understanding How Sanity Stores Datetimes

First, it's important to know that Sanity's standard datetime field type stores all values as ISO-8601 formatted strings in UTC. This is standard practice for databases and ensures data consistency, but you need a way to handle timezone-specific entry and display.

Solution 1: Standard Datetime Field with displayTimeZone

The standard datetime field now includes a displayTimeZone option that lets you lock the field to a specific timezone for all users. This is perfect if you want everyone to enter times in Pacific Time:

import { defineField } from 'sanity'

defineField({
  name: 'eventDate',
  type: 'datetime',
  options: {
    dateFormat: 'YYYY-MM-DD',
    timeFormat: 'HH:mm',
    timeStep: 15,
    displayTimeZone: 'America/Los_Angeles', // Forces Pacific Time (handles PST/PDT automatically)
  },
})

The key here is that displayTimeZone accepts a timezone identifier like 'America/Los_Angeles'. This automatically handles the PST/PDT transitions throughout the year—you don't need to specify both separately.

Important note: The data is still stored as UTC in your dataset (which is good!), but the Studio interface will display and accept times in Pacific Time.

You can also use allowTimeZoneSwitch: false if you want to prevent users from changing the timezone:

options: {
  displayTimeZone: 'America/Los_Angeles',
  allowTimeZoneSwitch: false, // Prevents users from switching timezones
}

Solution 2: The richDate Plugin

If you need users to be able to choose their own timezone and have that timezone information stored with the datetime, the @sanity/rich-date-input plugin is the solution. Unlike the standard datetime field, richDate stores the timezone information along with the date/time in the document itself.

Install it:

npm i @sanity/rich-date-input

Then in your schema:

import { defineField } from 'sanity'

defineField({
  name: 'eventDate',
  type: 'richDate',
  options: {
    timeStep: 15, // optional: set time picker intervals
  },
})

With richDate, users get a timezone dropdown where they can select their timezone (like "America/Los_Angeles"), and that selection is preserved in the document. This means:

  • A user in Los Angeles can enter "2:00 PM PST"
  • A user in New York can enter "5:00 PM EST"
  • The timezone context is stored and can be used when displaying the content

Which Should You Choose?

  • Use displayTimeZone option if you want all users to enter times in a single, consistent timezone (like Pacific Time) regardless of where they're located
  • Use the richDate plugin if you need to preserve which timezone each user was working in when they entered the time

Both solutions handle PST/PDT transitions automatically since they use standard timezone identifiers like "America/Los_Angeles" rather than explicit PST/PDT designations.

Displaying Times in Your Application

When querying and displaying these times in your frontend, remember to convert UTC values back to the appropriate timezone using libraries like date-fns-tz or luxon. The GROQ dateTime() function works with UTC timestamps, so you'll need to handle timezone conversion in your application code.

Which type are you using to save the dates in the schema? The dateTime -type says it saves the date in UTC.
The type in the schema is the richDate type. I guess my issue is not with sanity itself then. I guess to guide me in the right direction, how are others handling daylight savings with users entering the same time at different timezones…
I would probably convert all dateTimes to the same timezone on saving in order to have some common ground for comparison. Then I’d allow the users browsers to convert the dates back into their timezone. Potentially with information about which timezone it uses, so users dont assume the time is given for another timezone.

Dealing with time and timezones is a horrendous minefield of gotchas, so I would heavily recommend finding a battle-tested package and using it for all it is worth rather than attempting to handle everything yourself. 🙂
That would be exactly what I need. Does sanity allow for a datetime or richDate type field to be saved as a specific timezone?
Users are using the studio to enter date data.
My understanding is that there doesnt exist a
richDate
field by default in Sanity. If you read the documentation I linked in the first post you’ll see that the
dateTime
type automatically converts times to UTC when saving. 🙂
oh. I did install the sanity richDate plugin to get the timezone data for the entered user, hoping it would help me find a solution. Ok, I finally understand. Thanks for your help.
The
richDate
plugin does not seem maintained anymore. 🙂 The last official release was when it was still a member of Sanitys monorepo. It has been moved out of that into its own repo , but there have not been any releases associated with that repo since then.
The code in your plugin should probably still be the same tho. We can see that in the
schema used internally by the `richDate` plugin , the field
utc
uses
dateTime
.
Yeah, I just noticed that. I installed since there was a “Pro Tip” in the datetime type in the sanity docs.
https://www.sanity.io/docs/datetime-type

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.

Was this answer helpful?