Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using ZonedDateTime in HttpHeaders [SPR-15661] #20220

spring-projects-issues opened this issue Jun 13, 2017 · 1 comment

Consider using ZonedDateTime in HttpHeaders [SPR-15661] #20220

spring-projects-issues opened this issue Jun 13, 2017 · 1 comment


Copy link

@spring-projects-issues spring-projects-issues commented Jun 13, 2017

Sébastien Deleuze opened SPR-15661 and commented

As raised during discussing #20114, ideally we Spring Framework 5 API should exposed date/time with timezone in a consistent way, but currently HttpHeaders existing date/time fields are exposed with long while they should be exposed with ZonedDateTime like ContentDisposition.

The consensus was to deprecate current long based variants and to add new ZonedDateTime ones, but this is not possible easily on getters if we use the same method name and choosing other names like getDateAsZonedDateTime() is not super appealing.

Affects: 5.0 RC2

Issue Links:

  • #20114 Support missing properties from Content-Disposition spec
  • #20708 MockHttpServletResponse.getDateHeader fails with NPE for non-existing header
  • #21104 Overloaded convenience setters on HttpHeaders
  • #22103 Allow java.time types for setting the Last-Modified header
  • #20234 Use fixed GMT time-zone for WebSessionManager Clock

Referenced from: commits 1fa8410, 5c1d8c7

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 22, 2017

Sébastien Deleuze commented

Merged, see the commit log message for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants