MonthDay, YearMonth, and Time should all support parsing from time

[Manishearth]

TLDR: Temporal.PlainMonthDay.from("2025-06-01") should work.

https://tc39.es/proposal-temporal/#prod-TemporalMonthDayString

When we parse a PlainMonthDay from a string, it is allowed to be specified as either an AnnotatedMonthDay or an AnnotatedDateTime[~Zoned][~TimeRequired]. It's similar for PlainTime and PlainYearMonth.

Currently we dispatch to individual parse functions:

temporal/src/parsers.rs

Lines 690 to 695 in dc36a5b

	let mut record = match variant {
	ParseVariant::YearMonth => parser.parse_year_month_with_annotation_handler(handler),
	ParseVariant::MonthDay => parser.parse_month_day_with_annotation_handler(handler),
	ParseVariant::DateTime => parser.parse_with_annotation_handler(handler),
	ParseVariant::Time => parser.parse_time_with_annotation_handler(handler),
	}

This is incorrect. We could probably unconditionally attempt to parse a date_time here and fall back to month_day/time/etc where necessary, but I don't know how to handle the TimeRequired/etc stuff here. Do we just check the parse result?

[Manishearth]

Also I think https://tc39.es/proposal-temporal/#prod-DateSpecMonthDay means that 05-06 should parse, not just --05-06, but it seems like the code errors on that. That's an ixdtf bug.

[Manishearth]

Or maybe it isn't an ixdtf bug? Maybe that's Temporal-specifc?

@nekevss is the expert here

[nekevss]

Ah, shoot. This is holdover from early on when parse_month_day handled the fallback logic. I must have forgot to update parse_month_day when the code in ixdtf removed the fallback.

But these updates should probably occur primarily in the parse_x functions vs. parse_ixdtf.

[Manishearth]

@nekevss Should they? the IXDTF crate specifies IXDTF formats, whereas these merged formats are a Temporal spec contrivance.

[nekevss]

Preemptively, early edit: I probably could have been a bit more clear on what I was referring to in my above comments by parse_x. That was meant to refer to the temporal_rs glue functions, not the ixdtf methods.

TLDR: we just need to update parse_month_day to fix the above.

Below is some rambling that I had typed up before I realized that I probably didn't specify what I was referring to correctly above. But I still think it might be useful background / framing to the current state of parsing and where it should be improved.

As a baseline / background, the parsing logic here needs a more formal API and has for a while. The work on a TemporalParser has been started in #379, which should hopefully allow this code to be cleaned up and more formalized.

While it looks like the same as ParseISODateTime, parse_ixdtf is intended as a central helper that wraps the ixdtf parser so that the handler logic is isolated into one function. This is obviously debatable, and I'm more than open to changing it, especially given the shift to TemporalParser.

The general handling of the merged formats are isolated in parse_date_time and similar functions.

For the initially mentioned test, it looks like parse_month_day is missing its second call to parse_date_time like what occurs in parse_year_month. So an update to parse_month_day would address the above, bring the function in line with expected behavior, and also shouldn't block the ongoing work being done in #379.

[Manishearth]

Oh! Yeah, makes sense.