IronCalc DATEVALUE and TIMEVALUE accept spaces around separators

The issue, in one line

IronCalc returned a VALUE error on text dates and times that Excel reads fine, because both parsers split the text before the spaces around the separators were removed. The issue.

The cause

parse_datevalue_text trims the ends of the text and then cuts at the first space to drop a time part. For “2026 - 01 - 01” that cut leaves “2026”, and the parse fails before the per-part trim ever runs on the separators. parse_time_string trims only the two ends, so a time typed with spaces around the colon splits into two parts that each carry a space, which are not numbers, and the fixed patterns below it do not allow a space beside the colon either. Both issues came from a user pasting values out of Excel, where those spaces are accepted, so a workbook that opens correctly in Excel fails as soon as IronCalc recalculates it.

Where it lives

• base/src/functions/date_and_time.rs, parse_datevalue_text trims the ends and cuts at the first space, so a spaced date loses the very separators the later split needs
• base/src/functions/date_and_time.rs, parse_time_string trims only the ends, so a colon with a space on either side is split into non-numeric parts before any pattern is tried

The fix, planned in the free diagnosis

• Add squeeze_separator_spaces, a helper that drops whitespace directly before and after any of a given set of separators and keeps every other space. Each whitespace run is decided once, when the next non-whitespace character is reached, so the cost is linear in the length of the text.
• Apply it to / and - at the start of parse_datevalue_text, after the trim and before the time part is cut away, so “2026 - 01 - 01” followed by a time becomes “2026-01-01” and still loses its time part.
• Apply it to the colon in parse_time_string after the trim, so a time typed with spaces around the colon parses the same as one typed without them, and keeps the space before PM.
• Leave VALUE and parse_time_of_day alone. DATEDIF and the conditional formatting date bounds read text dates through parse_datevalue_text, so they pick up the change without further edits.

How it’s proven, in the sprint

• base/src/test/test_datevalue_timevalue_spaces.rs, datevalue_spaces_around_separators and timevalue_spaces_around_separators. The date test asserts 46023, 46024 and 46057 for the spaced separators and 46023 for a spaced date that carries a time part. The time test asserts that a spaced four thirty-five is not a VALUE error and equals the unspaced one, that a spaced noon is 0.5, and that a spaced half past three PM equals the unspaced one. On main at 09e81f53 every one of those checks fails.
• The same file, long_space_runs_around_separators, added after a review note about a long run of spaces. TIMEVALUE over the 32,000-space input from the report went from 4.69 s to 0.01 s in the debug build, and the helper’s output was unchanged against the first version on 600,000 generated inputs.
• The two workbooks from the issues, DATEVALUE_issue_1380.xlsx and TIMEVALUE_issue_1402.xlsx, added unchanged to xlsx/tests/calc_tests, so the generated tests compare cell B2 against the value Excel itself saved. Both fail on main and pass on the branch.
• ironcalc_base lib 2731 passed, generated tests 235 passed, rustfmt clean and clippy with -D warnings clean, and 2732 after the follow-up test.
• CI green on all five checks on the head commit, lint-all, test-rust on ubuntu-latest, test-rust on macos-latest, test-js and test-python.
• An automated reviewer flagged the first version of the helper as quadratic on long whitespace runs. The author rewrote it in 523ab79 and the reply on that thread carries the timings above, which is why the merged version is the linear one.

What wasn’t tested, said up front

The wasm, Python and Node.js binding suites and the webapp npm checks, as the PR states. No browser check of the recalculated cell in the sheet UI. Excel itself was not run here, so the expected values rest on the workbooks attached to the issues. The fix was read on GitHub and not rebuilt on this machine.

What happened next, after the sprint

It was merged on 2026-10-07 about 8 hours after it opened, with 84 lines added and 2 removed. Open the pull request.