Clarify exception for unknown standard patterns to point to % #971
Labels
Milestone
Comments
jskeet
added a commit
to jskeet/nodatime
that referenced
this issue
Oct 11, 2017
Sample: Unhandled Exception: NodaTime.Text.InvalidPatternException: The standard format "H" is not valid for the NodaTime.LocalDateTime type. If the pattern was intended to be a custom format, escape it with a percent sign: "%H". I haven't implemented the "detect whether it's a valid custom pattern" part - I think that would be a bigger (and slightly riskier) change without much benefit. Fixes nodatime#971.
jskeet
added a commit
that referenced
this issue
Oct 11, 2017
Sample: Unhandled Exception: NodaTime.Text.InvalidPatternException: The standard format "H" is not valid for the NodaTime.LocalDateTime type. If the pattern was intended to be a custom format, escape it with a percent sign: "%H". I haven't implemented the "detect whether it's a valid custom pattern" part - I think that would be a bigger (and slightly riskier) change without much benefit. Fixes #971.
jskeet
added a commit
to jskeet/nodatime
that referenced
this issue
Oct 12, 2017
Equivalent to 33c5f4a, but back when we still had resource files. Fixes nodatime#971 in the 2.2.x branch.
jskeet
added a commit
to jskeet/nodatime
that referenced
this issue
Oct 12, 2017
Equivalent to 33c5f4a, but back when we still had resource files. Fixes nodatime#971 in the 2.2.x branch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is somewhat unexpected that a custom pattern of (e.g.)
"HH"will work fine, but a custom pattern of"H"will throw an error (see e.g. #928), and needs to be specified as"%H"instead.We do document this in the user guide (http://nodatime.org/userguide/text, "Standard and custom patterns"), but it's a bit hidden.
It would be nice if the exception text ("The standard format "x" is not valid for the NodaTime.ZonedDateTime type.") explicitly mentioned the possibility of escaping a custom pattern.
(Perhaps it could do so conditionally based on whether
%xwas a valid custom format pattern; doing that is trivial, apart from the case ofInstantPatternParser.)The text was updated successfully, but these errors were encountered: