Skip to content

Conversation

@blarfoon
Copy link
Contributor

@blarfoon blarfoon commented Jun 29, 2025

Addresses #224

Copy link
Member

@nekevss nekevss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Thanks for working on this! I left a few review comments. Overall this is looking pretty good!

In general, the gist of the feedback is that the parser should ideally take utf8 and utf16 as primaries (a from_str method is an option assuming it calls str::to_bytes internally using the utf8 method).

For now, this can focus on primarily supporting utf8, but once ixdtf is bumped to its current main or a new version, the utf16 support will need to be added.

@nekevss nekevss added C-enhancement New feature or request C-api Changes related to the public API labels Jun 30, 2025
@nekevss
Copy link
Member

nekevss commented Jul 4, 2025

Quick follow up, the ixdtf bump should be available once #365 is merged.

@nekevss
Copy link
Member

nekevss commented Jul 15, 2025

Hi @blarfoon, are you able to fix the above?

@blarfoon blarfoon requested a review from nekevss July 16, 2025 17:12
Copy link
Contributor

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a lot of code duplication that will make it harder to maintain: the actual logic of the UTF8/UTF16 code paths should share code.

}

/// Converts a UTF-16 encoded string into a `PlainDate`.
pub fn from_utf16(s: &[u16]) -> TemporalResult<Self> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

n.b. temporal_capi has a bunch of internally-converting from_utf16s that probably can be swapped over to these

}

/// Parses the source into a `PlainDateTime` compatible record.
pub fn parse_date_time(&self) -> TemporalResult<ParsedDateTime<'a>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: ideally we link to exactly which part of the spec this implements: there are a lot of parseable things called DateTime

) -> TemporalResult<IxdtfParseRecord<'a, Utf16>> {
let record = self.parse_ixdtf_utf16(source, ParseVariant::DateTime)?;

if record.offset == Some(UtcOffsetRecordOrZ::Z) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: I think this code should be shared; same for the rest.

}
}

fn parse_ixdtf_utf16(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

observation: I also think this code should be shareable.

I think all of this can be made to operate on an IxdtfParser, and the end functions construct an IxdtfParser::from_whatever and pass it down.

Hell, I think the IxdtfParser can probably just be a field in TemporalParser.


fn parse_date_time_utf16(
&self,
source: &'a [u16],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: what's the point of taking both a source and self here? Both wrap the same string?

Copy link
Member

@nekevss nekevss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Manish that there is probably a good way to make the code shareable.

For reference -- if it's helpful at all -- the PR to add UTF16 support to ixdtf is here.

Self::DateTimeOutOfRange => {
TemporalError::range().with_message("Date/time is outside representable range")
}
Self::ParseError(msg) => TemporalError::syntax().with_message(msg),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this should probably be a RangeError

While it would be technically correct for this to be a syntax error, almost all syntax errors are thrown as range errors, so the general movement has been away from using them.

@jedel1043
Copy link
Member

@blarfoon do you still plan to work on this? This PR may have to be closed and rewritten since it got very outdated with the current repo.

@jedel1043
Copy link
Member

Closing this PR since it got stale.

@jedel1043 jedel1043 closed this Oct 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C-api Changes related to the public API C-enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants