Support java.time API in <fmt:parseDate> and <fmt:formatDate>

[BalusC]

It's about time.

We could use type attribute to indicate the expected type. E.g. type="localDate", type="localTime", type="localDateTime", type="zonedDateTime", etc. And in case of <fmt:parseDate>, the type of the instance behind the var should depend on type attribute as well.

[BalusC]

For the record, I used Mojarra's jakarta.faces.convert.DateTimeConverter (which I also worked on) as inspiration, especially wrt leniency and corner cases with u versus y years.

[pnicolucci]

This is great @BalusC thanks for preparing this and the implementation side. I'm working on defining a release plan for Jakarta EE12 and we should certainly include this.

[volosied]

First of all, thank you for making this PR!

I'm testing it out but I don't seem to be able to get this to work locally. I ported it over to Tags 3.0 (for local testing), but perhaps I made a mistake? Or is the code below incorrect?

<!-- Parse with zonedDateTime type -->
<fmt:parseDate value="2025-10-08 15:53:45 -0400" pattern="yyyy-MM-dd HH:mm:ss Z" 
               var="zonedDate" type="zonedDateTime" />

<!-- Set timezone for formatting -->
<fmt:setTimeZone value="Europe/Paris" />

<!-- Format with the timezone set above -->
<fmt:formatDate value="${zonedDate}" pattern="MMMM d, yyyy 'at' h:mm a z" 
                type="zonedDateTime" />
<!-- Expected Output: October 8, 2025 at 9:53 PM CEST -->

<!-- Change to Tokyo timezone -->
<fmt:setTimeZone value="Asia/Tokyo" />
<fmt:formatDate value="${zonedDate}" pattern="MMMM d, yyyy 'at' h:mm a z" 
                type="zonedDateTime" />
<!-- Expected Output: October 9, 2025 at 4:53 AM JST -->

Instead, I see October 8, 2025 at 3:53 PM -04:00 October 8, 2025 at 3:53 PM -04:00in the output. Could be something on my end, but I'll debug it.

[BalusC]

<fmt:setTimeZone>/<fmt:formatDate timeZone> is only applied when value is java.util.Date because it doesn't support holding time zone information.

In case of ZonedDateTime, the time zone is inferred from the ZonedDateTime instance itself. So you basically need 2 separate instances for ${zonedDate}, each with desired zone ID.

See also updated spec https://github.com/BalusC/tags/commit/c0660aa0f0adf36498446a1d6ff50d246911edba#diff-5ab48a1b5b52770c8d1fb44df3f3d960cf53213f602a5ec78f4646601b943620R4760-R4761