Add ZonedTime and use it in Combo docs #7532

sffc · 2026-01-31T00:24:26Z

First part of #5937
Last part of #6242

This PR was written with the help of Gemini CLI with some manual tweaks, which you can see in the commit history.

…_future()

components/datetime/src/scaffold/get_field.rs

components/datetime/src/combo.rs

robertbastian · 2026-01-31T09:22:25Z

ffi/capi/tests/missing_apis.txt

 icu::properties::script::HarfbuzzScriptData#Struct
 icu::properties::script::HarfbuzzScriptData::new#FnInStruct
 icu::properties::script::HarfbuzzScriptDataBorrowed#Struct
+icu::time::ZonedTime#Struct


sffc · 2026-02-02T09:06:54Z

My main motivation for this PR was testing gemini-cli. I don't intend to spend more time polishing this API by adding string parsing and FFI. If that is a problem, I can mark it as unstable.

robertbastian

My main motivation for this PR was testing gemini-cli. I don't intend to spend more time polishing this API

I spent time on reviewing this PR, so I expect you to spend time addressing my comments.

sffc · 2026-02-02T09:28:42Z

I can mark it as unstable.

^ I was asking for a reply to this.

robertbastian

I can mark it as unstable.

^ I was asking for a reply to this.

I don't want to add half-baked APIs just because you want to play around with Gemini. Either we do this correctly or we don't.

robertbastian · 2026-02-02T09:34:30Z

if not, I think it's more readable to parse a ZonedDateTime and then throw away the date, than to assemble this from parts. this aligns more with what clients will actually do, they have a ZDT but only want to display a ZT

sffc · 2026-02-02T09:35:26Z

A half-baked API is better landed on main than sitting in a PR.

sffc · 2026-02-02T09:47:38Z

I intend to push some code changes later when I'm back on the correct computer, but I'm still awaiting further discussion on whether ZonedTime without string and FFI is motivated to land, perhaps with an unstable feature.

If we land it, we can keep the issue open for string and FFI.

sffc · 2026-02-02T09:53:10Z

if not, I think it's more readable to parse a ZonedDateTime and then throw away the date, than to assemble this from parts. this aligns more with what clients will actually do, they have a ZDT but only want to display a ZT

It appears that RFC 9557 only defines suffixes as annotating a date-time, not a standalone date or time

https://www.rfc-editor.org/rfc/rfc9557.html#name-abnf

But, I think we allow annotations on dates?

robertbastian · 2026-02-02T10:07:12Z

We allow annotations on dates.

ISO-8601 allows times to be combined with offsets as well: https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

So we should parse the strings 12:34:56+01:00, 12:34:56Z, and probably 12:34:56+01:00[Europe/Zurich] into ZonedTime.

robertbastian · 2026-02-02T10:10:53Z

A half-baked API is better landed on main than sitting in a PR.

It's better to merge code than to keep PRs open. However I disagree with your statement when it comes to public APIs. I don't want to get into a situation where a non-trivial part of our API surface is unstable just because we wanted to get PRs merged.

sffc · 2026-02-03T02:49:12Z

It's better to have unstable APIs because subsequent PRs to get them closer to graduation are smaller and bite-size.

…parse a ZonedDateTime and create a ZonedTime from it

robertbastian

It's better to have unstable APIs because subsequent PRs to get them closer to graduation are smaller and bite-size.

This PR does the trivial work of adding the ZonedTime type and its 7 GetField implementations. The real work for adding this type has always been adding a ZonedTimeFormatter on FFI, and IXDTF parsing.

The issue is not in the milestone, so nobody is going to do the actual work for this release. As I said before, I don't want to have a half-baked (more like tenth-baked) API, even unstably. So far our unstable APIs have been things that we consider done, but we want to fine-tune for one release. This is not close to done.

This also does not fix the issue like you say in the PR description.

After rereading through the issue, I also still have concerns with this type overall.

robertbastian · 2026-02-03T08:47:37Z

components/datetime/src/combo.rs

+///     "2024-10-18T15:44:00-07:00[America/Los_Angeles]",
+///     Iso,


unnecessary change

robertbastian · 2026-02-03T08:49:08Z

components/time/src/types.rs

+#[derive(Debug, PartialEq, Eq, Copy, Clone)]
+#[allow(clippy::exhaustive_structs)] // this type is stable
+#[cfg(feature = "unstable")]
+pub struct ZonedTime<Z> {


issue: this needs to be reexported in datetime::input

It's fine to not while this is unstable IMO.

Manishearth

I think this is sufficiently motivated (see the discussion on the issue). I'm weakly negative on adding unmotivated experimental stuff (I think that is a recipe for "too much unstable"), but this has use cases, and we've had this issue open and in various milestones for a while. So no problem with landing it as unstable from my side. API looks mostly like what I expect.

sffc · 2026-02-04T17:47:31Z

This PR does the trivial work of adding the ZonedTime type and its 7 GetField implementations. The real work for adding this type has always been adding a ZonedTimeFormatter on FFI, and IXDTF parsing.

If users want this type today, they can write these 7 impls manually in userland, but I think the impls should live in the icu4x components.

The issue is not in the milestone

The WG previously said: "OK to add this type. Cool if it makes 2.0, OK if it doesn't." It didn't make it in 2.0, so then the issue got punted to Priority Backlog. This PR is the first step to solve the issue.

so nobody is going to do the actual work for this release.

We should keep the issue open.

As I said before, I don't want to have a half-baked (more like tenth-baked) API, even unstably. So far our unstable APIs have been things that we consider done, but we want to fine-tune for one release. This is not close to done.

I disagree strongly on a multiple dimensions here:

The current code is good. There are additional APIs that need to be added, sure, but the current code is code that will need to land either way, and it is code that needs to land first.
This API is basically done for Rust users. Additional convenience APIs may be added, but the examples demonstrate that this solves real problems for Rust users.
As a WG we are exceedingly nitpicky about things. I'm not saying this is bad, but the unstable feature is the escape hatch to let us make technical progress despite nitpicks.

This also does not fix the issue like you say in the PR description.

I will fix the PR description.

After rereading through the issue, I also still have concerns with this type overall.

Please comment on the issue with any new information that should make us revisit the WG conclusion.

Manishearth · 2026-02-04T19:06:33Z

If users want this type today, they can write these 7 impls manually in userland, but I think the impls should live in the icu4x components.

Adding to this, our GetField traits are there for people to use them if they really need, BUT they're unstable and probably should remain as unstable power user APIs, so we should create stable happy paths for use cases we find.

robertbastian · 2026-02-04T20:43:41Z

Please comment on the issue with any new information that should make us revisit the WG conclusion.

I have already done this in the issue since the WG decision.

sffc added 10 commits January 30, 2026 15:36

Agent version inline in docs

b9378b4

Agent implementation of ZonedTime in code

a4c094e

Human fixes

dfa33dd

Agent improving docs of ZonedTime

6742dd8

Human tweaks

5b11341

Agent: Make ZonedTime generic in Z

e49d04a

Agent: reduce verbosity of example by using ZoneNameTimestamp::far_in…

4f2efc5

…_future()

Human tweak

4cc0e3a

Agent: fix clippy and docs warnings

7da0e98

Human: add to missing_apis.txt

f854262

sffc marked this pull request as ready for review January 31, 2026 01:18

sffc requested review from Manishearth, nekevss, robertbastian and zbraniecki as code owners January 31, 2026 01:18

robertbastian reviewed Jan 31, 2026

View reviewed changes

sffc added the waiting-on-author PRs waiting for action from the author for >7 days label Feb 2, 2026

sffc removed the waiting-on-author PRs waiting for action from the author for >7 days label Feb 2, 2026

sffc requested a review from robertbastian February 2, 2026 09:07

robertbastian requested changes Feb 2, 2026

View reviewed changes

sffc requested a review from robertbastian February 2, 2026 09:28

robertbastian requested changes Feb 2, 2026

View reviewed changes

sffc requested a review from robertbastian February 2, 2026 09:35

sffc added 2 commits February 2, 2026 19:04

Mark it as unstable

75b2af4

Agent: Change the example in combo.rs that uses ZonedTime to instead …

f9711aa

…parse a ZonedDateTime and create a ZonedTime from it

sffc requested a review from a team as a code owner February 3, 2026 03:12

fmt

ef12606

robertbastian requested changes Feb 3, 2026

View reviewed changes

Manishearth approved these changes Feb 3, 2026

View reviewed changes

Merge branch 'main' into zonedtime

87d811f

sffc added the discuss-priority Discuss at the next ICU4X meeting label Feb 4, 2026

		/// "2024-10-18T15:44:00-07:00[America/Los_Angeles]",
		/// Iso,

Add ZonedTime and use it in Combo docs #7532

Are you sure you want to change the base?

Add ZonedTime and use it in Combo docs #7532

Uh oh!

Conversation

sffc commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

robertbastian Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

sffc commented Feb 2, 2026

Uh oh!

robertbastian left a comment

Choose a reason for hiding this comment

Uh oh!

sffc commented Feb 2, 2026

Uh oh!

robertbastian left a comment

Choose a reason for hiding this comment

Uh oh!

robertbastian commented Feb 2, 2026

Uh oh!

sffc commented Feb 2, 2026

Uh oh!

sffc commented Feb 2, 2026

Uh oh!

sffc commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robertbastian commented Feb 2, 2026

Uh oh!

robertbastian commented Feb 2, 2026

Uh oh!

sffc commented Feb 3, 2026

Uh oh!

robertbastian left a comment

Choose a reason for hiding this comment

Uh oh!

robertbastian Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

robertbastian Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Manishearth Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Manishearth left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sffc commented Feb 4, 2026

Uh oh!

Manishearth commented Feb 4, 2026

Uh oh!

robertbastian commented Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sffc commented Jan 31, 2026 •

edited

Loading

sffc commented Feb 2, 2026 •

edited

Loading

Manishearth left a comment •

edited

Loading