First of all, storing the JWT client-side is not only acceptable, it is mandatory; your client can't make authenticated requests if it doesn't have its session token. You can store it different places, each with their own security tradeoffs (a cookie is traditional, and can be hidden from script with the
httponly flag, but also needs to use the
secure flag and puts you at risk of CSRF and similar if you don't use the
samesite flag or your browser doesn't support it yet; persistent or session local storage won't be sent automatically the way cookies are and can protect against CSRF, but an XSS payload could steal them). It can be stored ephemerally (session storage or session cookies, although realistically, people often don't actually close their browsers these days) or persistently (its lifetime should be short enough, and included in the signed data of the token and therefore immutable, that this is probably safe but pointless). It's gotta be stored, though.
With that said, even if the token is stored in an httponly cookie (where script can't see it), there's no harm in storing the token's expiration time in local storage. I'm not sure what you plan to do with this data (warn the user when their session is running out? Submit a refresh token request?) but there's no security impact to doing so.
EDIT: A bit more background
JWTs include their expiration time / validity lifetime within themselves, in a portion that is cryptographically signed. Only the server can generate a valid signature, and if any of the signed data (including the expiry) is tampered with, the signature becomes invalid. A JWT with an invalid signature cannot be used (the server will reject it). The server will also reject a JWT that has expired, of course, so the server neither cares what the client thinks the expiration is, nor should ever ask anything except the JWT itself (including its timestamp and signature) whether it is currently valid.