Different behavior of the @DateTimeFormat when running on Local env and on Cloud env (Heroku)

[rayman245]

I noticed some inconsistency in the behavior of the @DateTimeFormat (DTF) annotation where passing the date "30-9-2024 7:41:00 pm" using @DateTimeFormat(pattern="d-M-yyyy h:mm:ss a") worked on my local but failed in cloud environment, and this was after upgrading the project from SB2 to SB3.3.3.

Tested out a few scenarios and below is my results:

not sure if could be related to spring-projects/spring-framework#30649 ?

[bclozel]

This is a duplicate of spring-projects/spring-framework#33151

[sbrannen]

Hi @rayman245,

For such issues, we are planning to suggest the use of fallback patterns that take a narrow non-breaking space (\u202F) into account.

In light of that, can you please confirm that the following addresses your issue?

@DateTimeFormat(pattern = "d-M-yyyy h:mm:ss a", fallbackPatterns = "d-M-yyyy h:mm:ss\u202Fa")

Thanks,

Sam

[rayman245]

Hi @sbrannen, for me the fix was more of changing in the format used. I suppose yes the above pattern would have worked as well.

But in my opinion, the workaround above isn't clean, as the non-breaking space is only for use prior to the 'a', and there is still normal space between the date and time. This would potentially lead to confusion and poor readability.

[sbrannen]

Thanks for the feedback, @rayman245.

for me the fix was more of changing in the format used.

What was the exact change you made?

as the non-breaking space is only for use prior to the 'a', and there is still normal space between the date and time.

That's correct. The primary pattern contains normal spaces, and the fallback pattern contains a narrow non-breaking space before the a in order to support that use case as well.

But in my opinion, the workaround above isn't clean,

I'm not quite sure what you mean by that.

Can you please explain?

---

p.s. For additional information on the subject, you may find the Date and Time Formatting with JDK 20 and higher wiki page I'm working on useful.

[rayman245]

Hello @sbrannen

What was the exact change you made?

We decided to use ISO_LOCAL_DATE_TIME instead, and we handle showing the AM/PM by formatting it again on the frontend.

I'm not quite sure what you mean by that.

Can you please explain?

Thanks again for providing the link to the wiki page, what I meant by 'not clean' was my initial concern with using a fallback pattern like '\u202F' readability. Most developers might not be aware of this issue and therefore not expect there to be a point in failure. Due to the elusiveness there is a chance that it could only be detected in production.

Another point I see is that the fallback pattern only works with UTF, I believe most projects may already be using UTF but some older projects may still be on the ISO-8859-1 encoding, and would be harder for them to refactor this.

Do let me know if I may be mistaken, as it could be a concern only on my end.

[sbrannen]

Thanks for the feedback, @rayman245.

We decided to use ISO_LOCAL_DATE_TIME instead, and we handle showing the AM/PM by formatting it again on the frontend.

That's a great way to handle that: use ISO standard formats for communication with the server and handle localization in the client. 👍

In the wiki page we also promote the use of ISO standard formats.

what I meant by 'not clean' was my initial concern with using a fallback pattern like '\u202F' readability. Most developers might not be aware of this issue and therefore not expect there to be a point in failure. Due to the elusiveness there is a chance that it could only be detected in production.

I'm pretty confident that most developers will not be aware of this, but that won't make the problem go away. That's why we created that wiki page... to raise awareness.

As for the readability of \u202F, yes that's not intuitive. So, I'd recommend documenting that it's a narrow non-breaking space in the code or Javadoc. That's exactly what I did in Spring Framework's own test suite, because I don't expect my colleagues to know what \u202F is. In fact, in a few years I'll probably forget as well. 😉

Another point I see is that the fallback pattern only works with UTF, I believe most projects may already be using UTF but some older projects may still be on the ISO-8859-1 encoding, and would be harder for them to refactor this.

That's true; however, Java source code should always be compiled with UTF-8 or UTF-16 (see JEP 400).

Though, the other potentially tricky part is that your application has to support UTF-8 for both input and output for date/time parsing and formatting, respectively. That's why I added a note about ISO-8859-1 and UTF-8 in that wiki page.

Do let me know if I may be mistaken, as it could be a concern only on my end.

I hope I've addressed your concerns.

Regards,

Sam