How to handle timezones in Sanity? Looking for date + time + timezone plugin

You're right to be surprised – there isn't a dedicated timezone plugin for Sanity, and that's because Sanity's datetime field doesn't actually store timezone information. It only stores UTC timestamps.

The allowTimeZoneSwitch and displayTimeZone options you might have seen in the datetime type only control how the datetime is displayed in the Studio UI – they don't capture or store which timezone an event actually belongs to. This is a common point of confusion.

The Reality: You'll Need to Build It

For your use case (storing date + time + timezone), you'll need to create a custom solution. Here are two practical approaches:

Option 1: Object with Datetime + Timezone String

Create a custom object type that combines a datetime field with a separate timezone field:

{
  name: 'scheduledEvent',
  type: 'object',
  fields: [
    {
      name: 'datetime',
      type: 'datetime',
      title: 'Date and Time'
    },
    {
      name: 'timezone',
      type: 'string',
      title: 'Timezone',
      options: {
        list: [
          {title: 'Eastern Time', value: 'America/New_York'},
          {title: 'Central Time', value: 'America/Chicago'},
          {title: 'Mountain Time', value: 'America/Denver'},
          {title: 'Pacific Time', value: 'America/Los_Angeles'},
          {title: 'UTC', value: 'UTC'},
          // Add more IANA timezone identifiers as needed
        ]
      }
    }
  ]
}

This stores both pieces of information separately, which you can then combine in your frontend using libraries like date-fns-tz or luxon.

Option 2: Store as ISO String with Offset

Alternatively, you could use a string field and store the complete ISO 8601 string with timezone offset (like 2024-03-15T14:30:00-04:00), but this requires more custom input handling in Studio.

Why richDate Isn't the Answer

The richDate plugin you mentioned was an attempt to improve the datetime input experience, but as you've discovered from the issues, it doesn't solve the timezone storage problem either. It's more focused on flexible date/time input formats than timezone handling.

The Path Forward

Since this is a common need (events, scheduling, etc.), building a reusable custom object type like Option 1 is your best bet. You could even package it as a plugin and share it with the community – there's clearly a gap here that others would benefit from!

The key is understanding that Sanity gives you the primitives (datetime for the timestamp, string for the timezone identifier), but combining them into a cohesive "datetime with timezone" experience is something you'll need to implement in your schema design and potentially with a custom input component if you want a polished UI.