-
Notifications
You must be signed in to change notification settings - Fork 8
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
The grammar element time-second may have the value "60" at the end of months in which a leap second occurs #4
Comments
I have investigated this a bit, and the problem is that this library depends on the Java 8
There is no support for holding such a value in the underlying library, and thus I have no straight-forward path to implement this. As you can see this will also fail:
|
I have a PR ready here: #5 All it really does is to ignore the 60-second value and replace it with 59 if the month, date, hour and second dictates that this might be a valid leap-second date-time. This may solve your issue if all you need is for the parser to not bork. Please let me know what you think. |
There is a way to parse leap second by java.time look at: https://stackoverflow.com/a/55310635/1306553 |
Yes, I'm well aware, thank you. However, there is no way to store the result of it, as |
ok then |
Hi again! I was curious what is your use-case for this. How are you encountering these leap-second date-times? Will this patch work for you? |
This has now been solved by introducing a |
Please, look https://tools.ietf.org/html/rfc3339 examples:
ITU cannot parse these date-times.
RFC3339 documentation says:
The text was updated successfully, but these errors were encountered: