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.

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

Feature: optional padding #365

Open
kunyavskiy opened this issue Mar 6, 2024 · 3 comments
Open

Feature: optional padding #365

kunyavskiy opened this issue Mar 6, 2024 · 3 comments

Comments

@kunyavskiy
Copy link

Padding class now suggests only strict options. You either have NONE or ZERO or SPACE. Same for formating and parsing.

It looks like a common usecase to have a flexible parser but strict formatted.

This can be implemented now as

alternativeParsing({ year(Padding.NONE) }) { year(Padding.ZERO) }

But this is quite verbose and probably suboptimal. I suggest to add Padding.OPTIONAL_ZERO and maybe something else similar. to fix it.

@dkhalanskyjb
Copy link
Contributor

dkhalanskyjb commented Mar 7, 2024

Fair. We should either provide a better way to do it or at least make this code behave optimally (which is doable).

Some arguments against adding OPTIONAL_ZERO:

  • If you have several fields, the verbosity is amortized and not as bad:
alternativeParsing({
  year(Padding.NONE); char('-'); monthNumber(Padding.NONE); char('-'); dayOfMonth(Padding.NONE)
}) {
  year(); char('-'); monthNumber(); char('-'); dayOfMonth()
}
  • When we researched how people use datetime formatting, most of the formats we looked at were used for either parsing or formatting, but not both. For people only using formats for formatting, Padding.OPTIONAL_ZERO is equivalent to Padding.ZERO, and for people only using parsing, it's equivalent to Padding.NONE. So, both classes of people get one more meaningless choice in the API. For formats that are used for both parsing and formatting, it may still help to clearly indicate the format that will be used for formatting, without having to sift through parsing-specific behavior, and alternativeParsing does that.

Let's collect more feedback and see how widespread the problem is. Everyone, please don't hesitate to share the ugly code that you're forced to write. Maybe we'll help you improve it, or maybe we'll see that OPTIONAL_ZERO is an absolute necessity.

@kunyavskiy
Copy link
Author

Will it parse something like 2024-3-07? I'm not sure if Padding.NONE allows having padding.

But I agree, that reusing for both formatting and parsing is not a common case.

@dkhalanskyjb
Copy link
Contributor

Will it parse something like 2024-3-07?

Yes.

I'm not sure if Padding.NONE allows having padding.

It does. We'll include this in the documentation, this information is missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants