Skip to content

fix(Foundation): %c format specifier emits centiseconds (#3949)#5350

Merged
matejk merged 1 commit into
mainfrom
3949-datetimeformatter-centisecond
May 13, 2026
Merged

fix(Foundation): %c format specifier emits centiseconds (#3949)#5350
matejk merged 1 commit into
mainfrom
3949-datetimeformatter-centisecond

Conversation

@matejk
Copy link
Copy Markdown
Contributor

@matejk matejk commented May 11, 2026

Summary

The %c specifier was documented as "centisecond" but emitted a single-digit decisecond (millisecond / 100). Bring the implementation in line with the documentation: %c now formats and parses a zero-padded two-digit centisecond value (00 .. 99), i.e. millisecond / 10.

Affects DateTimeFormatter (DateTime and Timespan overloads), DateTimeParser, and PatternFormatter. The format/parse pair stays consistent so round-tripping a value via "%H:%M:%S.%c" preserves centisecond resolution.

Updated docs in DateTimeFormatter.h and PatternFormatter.h to read "centisecond (00 .. 99)". Added focused testFractionalSpecifiers to both DateTimeFormatterTest and DateTimeParserTest covering boundary values and a format/parse round trip. Adjusted the existing testCustom assertion that hard-coded the old single-digit output.

Behavioural change: callers that relied on %c producing a single digit will now see one extra character. PatternFormatter timestamps using %c (e.g. the Logger and FastLogger samples' "%H:%M:%S.%c") gain one character. Worth a CHANGELOG note.

Closes #3949.

Test plan

  • All 949 Foundation tests pass on macOS arm64
  • CI green on Linux/Windows
  • Confirm the behavioural change is acceptable for a 1.15.x patch release (alternative: defer to 1.16.0)

@matejk matejk added this to the Release 1.15.3 milestone May 11, 2026
@matejk matejk added bug breaking A breaking change labels May 11, 2026
@matejk matejk requested review from aleks-f and obiltschnig May 11, 2026 17:56
Documentation describes %c as "centisecond" but the implementation was
emitting a single-digit decisecond (millisecond / 100). Bring the code
in line with the documentation: %c now formats and parses a zero-padded
two-digit centisecond value (00 .. 99), i.e. millisecond / 10.

Affects DateTimeFormatter (DateTime and Timespan overloads),
DateTimeParser, and PatternFormatter. The format/parse pair stays
consistent so round-tripping a value via "%H:%M:%S.%c" preserves the
centisecond resolution.

Updated docs in DateTimeFormatter.h and PatternFormatter.h to read
"centisecond (00 .. 99)". Adjusted the existing testCustom assertion
that hard-coded the old single-digit output, and added focused
testFractionalSpecifiers tests in both DateTimeFormatterTest and
DateTimeParserTest covering the boundary values and a format/parse
round trip.

Note: this is a behavioural change for callers that relied on %c
producing a single digit. PatternFormatter timestamps that include %c
(e.g. the format used by the Logger and FastLogger samples,
"%H:%M:%S.%c") will now contain one extra character.
@matejk matejk force-pushed the 3949-datetimeformatter-centisecond branch from 264999c to 719aac5 Compare May 13, 2026 15:48
@matejk matejk merged commit f20351b into main May 13, 2026
93 of 94 checks passed
@matejk matejk deleted the 3949-datetimeformatter-centisecond branch May 13, 2026 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking A breaking change bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Poco::DateTimeFormatter %c does not format to centisecond but decisecond

1 participant