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.

Sign up for GitHub

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

Jump to bottom

Java8 Date/Time formats #235

Open
petekaras opened this issue Jul 12, 2017 · 13 comments · May be fixed by #884
Open

Java8 Date/Time formats #235

petekaras opened this issue Jul 12, 2017 · 13 comments · May be fixed by #884
Labels
jdk8 Changes related to migrating to JDK8 API features
Milestone
1.0

Comments

@petekaras
Copy link

Hi,
Maybe I'm missing something so apologies if this is not an issue.
I've configured my spring boot application to use jackson-datatype-jsr310 by including in pom.xml, all outgoing json is serialized correctly.
however I am using a hashmap to set the payload of the the jwt token:

hashMap.put(Claims.ISSUED_AT,LocalDateTime.now);

and this is being serialized in the Long LocalDateTimeFormat:

{"hour":9,"minute":53,"second":49,"nano":288000000,"dayOfYear":193,"dayOfWeek":"WEDNESDAY","month":"JULY","dayOfMonth":12,"year":2017,"monthValue":7,"chronology":{"calendarType":"iso8601","id":"ISO"}

I had a similar issue in another spring boot application where I was using new ObjectMapper() and not using springBoots configured ObjectMapper.
Any ideas how I could make jjwt pick up springboots ObjectMapper which would be configured correctly ?
I'm using using jjwt version 0.7.0.

Thanks in advance for your help,
Peter
@lhazlewood
Copy link
Contributor

Unfortunately you cannot currently specify the ObjectMapper that the JwtBuilder will use to generate the resulting JSON. Yet. :)

We'll use this issue to track the work to allow you to do so :)

That said, would you say this issue should be classified as "Allow me to set my own ObjectMapper" ?

Or is the issue really "Please support Java8 Date/Time formats ?

Thoughts?

Thanks for the issue!

@petekaras
Copy link
Author

Hi Les,
Yes, I think this is really about supporting Java8 formats.
I would be happy to contribute to this project, but am short of time right now. Will let you know if I can help out in the future if you are looking for contributors ?

@petekaras petekaras changed the title Java8 jsr310 LocalDateTime Please support Java8 Date/Time formats Oct 22, 2017
@lhazlewood lhazlewood added this to the 1.0 milestone Nov 1, 2017
@simdevmon
Copy link

It would be nice to have overloaded methods e.g. in Claims e.g.

public Claims setExpiration(LocalDateTime date);
public Claims setNotBefore(LocalDateTime date);
public Claims setIssuedAt(LocalDateTime date);

Would you accept a PR for that?

@lhazlewood lhazlewood changed the title Please support Java8 Date/Time formats Java8 Date/Time formats Jul 11, 2018
@lhazlewood lhazlewood mentioned this issue Jul 11, 2018
Closed
@lhazlewood
Copy link
Contributor

Depends on #308.

@lhazlewood
Copy link
Contributor

lhazlewood commented Jul 11, 2018 •
edited

This ticket would add support for claims of type:

Anything else?

@cassiomolin
Copy link

Can we add OffsetDateTime to the list?

@marschall
Copy link

marschall commented Aug 6, 2019 •
edited

I would not support LocalDateTime. LocalDateTime is not an instant and therefore does not identify a point in time. You would need a time zone for that. Which means you don't know how much time has passed since a claim was issued which means that you don't know whether it is expired.

Even the JSR-310 expert group leader thinks LocalDateTime is not generally useful.
tc39/proposal-temporal#7 (comment)

@RockyMM
Copy link

RockyMM commented Jan 4, 2020

@marschall I completely agree. LocalDateTime is ambiguous. However, Instant has far too many advantages over java.util.Date. I will check other tickets for progress on of deprecation of java.util.Date.

@marschall
Copy link

@RockyMM sure, Instant, OffsetDateTime and ZonedDateTime are a great addition and completely fine.

@lhazlewood lhazlewood mentioned this issue Mar 17, 2020
Closed
@imhansai
Copy link

Hi, it's 2023, any good news?

@bdemers
Copy link
Member

bdemers commented Apr 19, 2023

Once #279 is in, Java8 support is next!

@lhazlewood lhazlewood mentioned this issue Aug 11, 2023
Closed
@lhazlewood lhazlewood added the jdk8 Changes related to migrating to JDK8 API features label Sep 5, 2023
@lhazlewood lhazlewood mentioned this issue Sep 13, 2023
Closed
@bartsopers
Copy link

What's the status of this issue?

@lhazlewood
Copy link
Contributor

@bartsopers Not yet implemented, but it will be, likely after the holidays. All of our energy was focused on 0.12.0, so now that it's out, we will focus on other 1.0 issues (like this one) soon.

pveeckhout added a commit to pveeckhout/jjwt that referenced this issue Dec 25, 2023
@pveeckhout
jwtk#235 Replace usage of java.util.Date with java.time.Instant in JW…
9bdbb85 
…T claims

This commit replaces the usage of java.util.Date with java.time.Instant in handling JWT claims. This means upgrading from JDK7 to JDK8. This is done for better adherence to ISO 8601 standards and better precision in time-related operations. Classes working with claims have been updated to use the newer Instant class, providing better precision and cross-timezone compatibility. Additionally, overloading convenience methods for setting OffsetDateTime and ZonedDateTime on top of Instant have been added on the JwtBuilder and DefaultJwtBuilder.
@pveeckhout pveeckhout linked a pull request Dec 25, 2023 that will close this issue
Open
pveeckhout pushed a commit to pveeckhout/jjwt that referenced this issue Dec 26, 2023
jwtk#235 Update JWT for default Instant usage
0921e29 
The JWT handling has been updated to default to Java's Instant class. This change removed support for various date and time classes such as ZonedDateTime, OffsetDateTime, Date, and Calendar in favor of an Instant-based approach throughout the codebase. The appropriate tests and documentation were updated to reflect this change.
pveeckhout added a commit to pveeckhout/jjwt that referenced this issue Dec 27, 2023
@pveeckhout
jwtk#235 Replace 'Date' with 'Instant' in JwtParserTest
54f3a19 
Replaced all instances of 'Date' with 'Instant' in JwtParserTest to more accurately reflect variable usage. Also added a TODO in JwtDateConverter.java to clarify the handling of epochMillis vs epochSeconds.
pveeckhout added a commit to pveeckhout/jjwt that referenced this issue Dec 27, 2023
@pveeckhout
jwtk#235 Update project version to 1.0.0-SNAPSHOT
fd1728c 
This commit updates the version of the project across all pom.xml files from 0.12.4-SNAPSHOT to 1.0.0-SNAPSHOT as it prepares for a major release. Changes cover the core project and various extensions, signaling a coordinated upgrade across the codebase.
pveeckhout added a commit to pveeckhout/jjwt that referenced this issue Dec 27, 2023
@pveeckhout
jwtk#235 Replace usage of Date with Instant
13a83b6 
All instances of java.util.Date in code have been replaced with java.time.Instant for better time precision and timezone handling. This includes changes in variable names, method names, test cases, comments and documentation. The java.util.Date-based utilities have also been removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
jdk8 Changes related to migrating to JDK8 API features
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

#235 Replace usage of java.util.Date pveeckhout/jjwt
9 participants
@bdemers @lhazlewood @marschall @RockyMM @cassiomolin @petekaras @bartsopers @simdevmon @imhansai