Feature request: Signature overload for time methods in builder

[oliverhausler]

It would be nice to see a second signature overload for .setExpiration(long), setIssuedAt(long) etc. which takes a long value instead of a date.

[lhazlewood]

This was (initially) avoided due to possible confusion: JWTs represent time values as seconds since epoch (not millis) but Java longs usually represent millis since epoch.

A single long scalar value allows ambiguity that can only be understood by reading JavaDoc, whereas the current method signatures avoid this problem entirely.

[lhazlewood]

additionally, there is nothing wrong with just calling:

setExpiration(new Date(yourLongValue))

[oliverhausler]

Oh, I didn't realize they used seconds in the JWT specs. Then I would have used Date as well to avoid confusion.