https://bugs.documentfoundation.org/show_bug.cgi?id=167201
Bug ID: 167201
Summary: Parsing logic for Year-Month-Time format incorrectly
validates the Hour component as a Day
Product: LibreOffice
Version: 25.2.1.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Description:
Calc actively attempts to parse ambiguous strings like 15-1-12:30. It
interprets such an input as having a YYYY-MM-HH:MM format with an omitted day,
which it then defaults to 1.
However, the parsing logic is flawed. It incorrectly validates the hour
component of the time as if it were a day-of-the-month. This misapplied
validation, which appears in the maybeiso8601 function, leads to inconsistent
outcomes based on a "magic number" threshold of 31—a limit that is extremely
counter-intuitive for a time value.
Steps to Reproduce:
1. Enter "15-1-31:30" in a cell
2. Enter "15-1-32:30" in another cell
Actual Results:
1. It is parsed as a Datetime(2015, 1, 2, 7, 30, 0) = Date(2015, 1, 1) +
time(31, 30, 0)
2. It is parsed as Text
Expected Results:
Ensure consistent and intuitive date-time parsing
or
disable parsing for this ambiguous format entirely and treat all such inputs as
plain text
Reproducible: Always
User Profile Reset: No
Additional Info:
Version: 24.8.3.2 (AARCH64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 8; OS: macOS 15.0; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_CN.UTF-8); UI: en-US
Calc: threaded
--
You are receiving this mail because:
You are the assignee for the bug.
