feat: add displayTimezone option to datetime input

[EoinFalconer]

Description

Adding the ability to add a displayTimezone option to the datetime input. This allows you to specify the timezone in which the stored UTC string from content lake will be displayed. When enabled, a tooltip is shown at the bottom left of the input field which indicates the timezone the field is representing. When you start editing this disappears.

A common use case here could be anything local that you would be working on in another timezone, for example concert times, apartment viewing times etc. etc. which are hard to work with today as the studio (just like the Date API) respects only the browsers relative display of the UTC string.

We have lots of signal on this one in this thread, as well as directly from users.

In addition to this, I decided to give it a go of removing moment from the @sanity/util package as a testbed how we should go about removing it across the entire codebase.

I am using the new date-fns/tz and date-fns/utc packages from date-fns. The reason for these is that they are very lightweight, TZDateMini which I am using here is only 916 B, which is a whopper difference from the locale bloat from moment-timezone dep we would need to make this work with moment.

As we have the ability to add custom date formats via the options on the datetime input and this is documented as support moment.js formats, I decided to write a formatter that would use the Intl.DateTimeFormat.format functionality instead by mapping the moment formatting to that format object.

What to review

• The naming of displayTimezone is worth a discussion.
• The UI that I have chosen, with the text below should also be taken into consideration as to whether that is the best approach.
• Browser support, not baking locales and timezones into the package and instead relying on the Intl.DateTimeFormat browser API means that browser versions outside the widely supported will not work.

Testing

I added two tests where I thought they should go that take account for this being in place and for Winter and Summer timezones. Happy to add more should we sit fit!

Notes for release

Might actually be worth mentioning: "The ability to specify the display timezone for your datetime fields".

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2025 4:36pm
performance-studio	✅ Ready (Inspect)	Visit Preview		Jan 14, 2025 4:36pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2025 4:36pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Jan 14, 2025 4:36pm
test-next-studio	⬜️ Ignored (Inspect)	Visit Preview		Jan 14, 2025 4:36pm

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Jan 14, 2025 4:39 PM (UTC)

✅ All Tests Passed -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 13s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	12s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	40s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	51s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	14s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	27s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 7s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 27s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 39s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 43s	21	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0

[github-actions]

⚡️ Editor Performance Report

Updated Tue, 14 Jan 2025 16:40:44 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
synthetic (title)	18.5 efps (54ms)	19.2 efps (52ms)	-2ms (-3.7%)	✅
synthetic (string inside object)	18.5 efps (54ms)	18.9 efps (53ms)	-1ms (-1.9%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
synthetic (title)	54ms	57ms	59ms	267ms	1033ms	12.9s
synthetic (string inside object)	54ms	56ms	67ms	528ms	1313ms	8.6s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
synthetic (title)	52ms	55ms	65ms	289ms	902ms	13.3s
synthetic (string inside object)	53ms	55ms	64ms	476ms	1229ms	8.5s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[rexxars]

This is a great addition. Could you add an example to the datetimeTest schema type in the test studio so we can more easily test this on a preview deployment?

NAD (Not A Designer), but from my perspective I'd love it if there was some way to reveal more information.

• If the users' timezone is not the same as the display timezone, having a way to show what the chosen time is in "your" timezone can be helpful.
• Potentially showing what the stored UTC time is (possibly also hinting that this is the "stored value")

I'm pondering if it might make sense to always show the timezone being displayed, and hide the additional information I mentioned behind a tooltip/info icon or similar. Currently (in next) I could see people putting in a date and forgetting that they might be in a different timezone than what they usually are and end up with an incorrect value being stored.

[EoinFalconer]

This is a great addition. Could you add an example to the datetimeTest schema type in the test studio so we can more easily test this on a preview deployment?

NAD (Not A Designer), but from my perspective I'd love it if there was some way to reveal more information.

• If the users' timezone is not the same as the display timezone, having a way to show what the chosen time is in "your" timezone can be helpful.
• Potentially showing what the stored UTC time is (possibly also hinting that this is the "stored value")

I'm pondering if it might make sense to always show the timezone being displayed, and hide the additional information I mentioned behind a tooltip/info icon or similar. Currently (in next) I could see people putting in a date and forgetting that they might be in a different timezone than what they usually are and end up with an incorrect value being stored.

Thanks for the feedback! 🙌 I think I'll run this by a designer as you bring up good points!

Would be good to get a stamp of approval on it, but I think given the use cases in this thread whereby you are inputting data for a specific show at an opera house or property viewing that is very local you always just want it to be fixed, so I'm not sure I'm seeing the need to change the timezone use case (maybe this could be added in the future with a allowTimezonePicker option, or even you can return a list of timezones that you would like it to be shown in if you require multiple for your business and don't want to store the date in many fields to achieve this.

Also not sure why an editor would want to know the utc time? Could be a useful devtool thing though if you don't want to have to go to vision to see your data?

[rexxars]

I'm not sure I'm seeing the need to change the timezone use case (maybe this could be added in the future with a allowTimezonePicker option

Sorry, I wasn't being precise in my feedback; the thing I was trying to address was that you don't know what timezone the date you are entering represents. Are you entering a UTC date? Your local timezone? The timezone the developer chose when they configured the schema?

Your PR addresses the last one; but only if you've set a display timezone. I am asking myself if seeing the timezone is so helpful that it should always be visible, even if the developer has not set a timezone explicitly. If no display timezone is set, it would show the users' local timezone, as that is what the default behavior is. Does that make sense?

Also not sure why an editor would want to know the utc time? Could be a useful devtool thing though if you don't want to have to go to vision to see your data?

Yeah, I may be overindexing on myself as a developer here. I keep seeing people stumble when they try to use the date in their frontends, thinking that the date stored is the same as the one they are seeing, but surfacing the UTC date to all users because of this is probably excessive.

[bobinska-dev]

I can add some more context on the use cases and customer needs here: https://sanity-io.slack.com/archives/C3Q637VGW/p1737038508203349