Feature: optional padding

[kunyavskiy]

Feature: optional padding

[dkhalanskyjb]

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]

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]

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.