Add java.time Instant, Year, YearMonth and MonthDay support to DateTimeConverter

[BalusC]

The type attribute of DateTimeConverter / <f:convertDateTime> now also accepts "instant", "year", "yearMonth" and "monthDay", corresponding to java.time.Instant, java.time.Year, java.time.YearMonth and java.time.MonthDay.

Default format

None of these four types can be formatted or parsed with a localized date/time style — DateTimeFormatter.ofLocalizedDate() throws UnsupportedTemporalTypeException for all of them (missing DayOfMonth, or YearOfEra for MonthDay), and java.time exposes no API for the CLDR available-formats (yMM, Md) that would be needed to derive a localized year-month or month-day pattern. Hence dateStyle and timeStyle are ignored for these types and, when no pattern is specified, the ISO 8601 form of the type is used:

type	default format	equals
instant	DateTimeFormatter.ISO_INSTANT	Instant.toString() / Instant.parse()
year	uuuu	Year.toString() / Year.parse()
yearMonth	uuuu-MM	YearMonth.toString() / YearMonth.parse()
monthDay	--MM-dd	MonthDay.toString() / MonthDay.parse()

This follows the existing offsetTime/offsetDateTime/zonedDateTime types, which also use a fixed ISO formatter and ignore the styles. Parsing stays strict, as the spec requires: ResolverStyle.STRICT with IsoChronology, so 2026-13 and --02-30 are rejected while --02-29 is accepted.

Time zone

An Instant carries no zone, so for the type instant the timeZone property is passed to the underlying DateTimeFormatter. Without it a pattern containing date or time fields cannot be resolved and formatting blows up. ISO_INSTANT itself always renders in UTC regardless, which is documented.

Message selection

The four new types are added to the message selection in getAsObject(). A type absent from that switch falls through the catch without throwing, which would have silently converted unparseable input to null.

Not included

java.time.Duration and java.time.Period from the issue are deliberately left out: they are TemporalAmount, not TemporalAccessor, so DateTimeFormatter cannot handle them at all. They warrant their own converter, to be discussed separately.

Tests

• DateTimeConverterTest: ISO round-trip per type, explicit patterns, instant with a pattern in Europe/Amsterdam, leap day, and ConverterException on unparseable input. 153 tests green in the api module.
• TCK: Spec2211IT + spec2211.xhtml + Spec2211Bean under tck/faces50/converters, covering the same through <f:convertDateTime>. Compiles; not yet run against a container.

Closes #2211

🤖 Generated with Claude Code (Opus 5)