Skip to content

Use DateTimeFormatter instead of SimpleDateFormat in RenderableDate - #3100

Merged
tomakehurst merged 1 commit into
wiremock:masterfrom
pivovarit:date-time-formatter
Nov 13, 2025
Merged

Use DateTimeFormatter instead of SimpleDateFormat in RenderableDate#3100
tomakehurst merged 1 commit into
wiremock:masterfrom
pivovarit:date-time-formatter

Conversation

@pivovarit

@pivovarit pivovarit commented Jul 9, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor

Replaced SimpleDateFormat with DateTimeFormatter in RenderableDate for the sake leveraging more user-friendly formatting.

For example, if you use template like {{now format="yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"}} to format "2025-07-07T15:23:11.123000Z", this is what you get:

  • DateTimeFormatter: 2025-07-07T15:23:11.123000Z (as expected)
  • SimpleDateFormat: 2025-07-07T15:23:11.000123Z (with milliseconds converted into microseconds)

The new test fails when run against the SimpleDateFormat-based implementation:

RenderableDateTest > handlesCorrectlyFormatsExcessivePrecision() FAILED
    java.lang.AssertionError: 
    Expected: is "\"2024-10-18T15:48:24.010000Z\""
        but: was "\"2024-10-18T15:48:24.000010Z\""

Submitter checklist

  • Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
  • The PR request is well described and justified, including the body and the references
  • The PR title represents the desired changelog entry
  • The repository's code style is followed (see the contributing guide)
  • Test coverage that demonstrates that the change works as expected
  • For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

@pivovarit
pivovarit marked this pull request as ready for review July 9, 2025 13:30
@pivovarit
pivovarit requested a review from a team as a code owner July 9, 2025 13:30
tomakehurst
tomakehurst reviewed Jul 9, 2025
View reviewed changes
Comment thread ...com/github/tomakehurst/wiremock/extension/responsetemplating/helpers/RenderableDateTest.java
@Test
void writesToJsonInStringFormat() {
RenderableDate renderableDate = new RenderableDate(new Date(1729266504000L), null, null);
RenderableDate renderableDate = new RenderableDate(new Date(1729266504010L), null, null);

@tomakehurst tomakehurst Jul 9, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Seems a bit dodgy that it's necessary to change this for the test to continue passing. What's happening here?

@pivovarit pivovarit Jul 9, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It's not necessary - added it to make the test more relevant. Default formatter truncates milliseconds, but the assertion won't show that because milliseconds part is just zeroes

@pivovarit pivovarit Jul 9, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Another change I'd like to submit it so actually stop cutting milliseconds off by the default formatter

@tomakehurst

tomakehurst commented Jul 9, 2025

Copy link
Copy Markdown
Member

I'm concerned this is not a completely backwards-compatible change. To your knowledge, are there date/time patterns that will work differently post this change?

@pivovarit

pivovarit commented Jul 9, 2025

Copy link
Copy Markdown
Contributor Author

DateTimeFormatter supports all the letter from the official reference: https://docs.wiremock.io/response-templating/dates-and-times#format-string-reference

When it comes to parsing behaviour, generally, DateTimeFormatter is more strict by default

For example:

  • format: "dd/MM/yyyy"
  • input: "1/1/2020"

SimpleDateFormat parses it correctly despite format expecting minimum two digits per day/month, the other throws DateTimeParseException. That's probably the major difference.

To maximize compatibility, we could fall back to SimpleDateFormat if default DateTimeFormatter fails

@tomakehurst

tomakehurst commented Jul 9, 2025

Copy link
Copy Markdown
Member

@leeturner WDYT?

Seems like 4.x beta is a good place to make what probably amounts to a fairly minor set of breaking changes.

@leeturner

leeturner commented Jul 9, 2025

Copy link
Copy Markdown
Contributor

@leeturner WDYT?

Seems like 4.x beta is a good place to make what probably amounts to a fairly minor set of breaking changes.

I would say definitely 4.x beta

@pivovarit

pivovarit commented Jul 9, 2025

Copy link
Copy Markdown
Contributor Author

A backward-compatible change that would mitigate the original issue would be to expand the default format to include milliseconds - no one would be forced to recreate ISO-8601 with milliseconds by hand (just like I did)

@pivovarit pivovarit mentioned this pull request Jul 10, 2025
Open
6 tasks
@tomakehurst
tomakehurst merged commit e2f27d5 into wiremock:master Nov 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tomakehurst tomakehurst tomakehurst left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@pivovarit @tomakehurst @leeturner