DefaultConfigProperties duration parsing: intentionally lenient?

[ljnelson]

Hello! To my naïve eyes, it looks like DefaultConfigProperties parses durations very leniently, at least as far as the specification is concerned, even permitting negative durations. Is this intentional?

[AZapata27]

Partly historical, and the negative case looks like a real gap rather than a choice.

The unit suffixes predate the spec wording. getDuration already took {number}{unit} with ms/s/m/h/d back in 1.0.0, and the stable SPI Javadoc still documents that format (ConfigProperties.java; ns/us were added to the list in #8899 last month). The "integer number of milliseconds, non-negative" text only landed in the spec in January 2025 with spec#4331. A bare integer is still read as milliseconds, so spec-style values behave as expected; the suffixes are a superset, and removing them now would break existing configs.

Negative values are a different story. The spec says MUST warn, ignore and fall back to the default. Here -5s parses to PT-5S and goes straight to the component. For otel.bsp.schedule.delay that's BatchSpanProcessorBuilder.setScheduleDelay, which does checkArgument(delay >= 0, ...) (L62), and autoconfigure turns that into a ConfigurationException("Unexpected configuration error"). So you get a failed startup instead of a warning plus the default.

I ran a few values through DefaultConfigProperties from 1.66.0 to see how far the leniency goes:

"-5s"                  -> PT-5S
"5 s"                  -> PT5S
"+5"                   -> PT0.005S
"9223372036854775807d" -> PT2562047H47M16.854775807S   (saturates, no error)
"1.5s", "5S", "PT5S"   -> ConfigurationException

I'd open an issue for the negative case. It's a small check in getDuration (log a warning and return null, so the caller keeps its default). Tightening the format itself is the maintainers' call, and I doubt they'd do it given the compatibility cost.