https://bugs.documentfoundation.org/show_bug.cgi?id=172789
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from [email protected] --- I confirm behaviour in Version: 26.8.0.3 (X86_64) Build ID: bce0998afefdbc355585ca324285661a2170ba77 CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded There is a closely related DATEDIF end-of-month issue in bug 171969, concerning the "md" interval. I have added further technical information there. In particular, ScInterpreter::ScGetDateDif() explicitly implements Excel's roll-over behavior for "md" by constructing potentially invalid dates and calling Date::Normalize(), which can produce negative remaining-day values. Although bug 172789 concerns interval "m" and bug 171969 concerns "md", both raise the broader question of how Calc should handle end-of-month semantics in its ODF/OpenFormula DATEDIF implementation, and when Excel compatibility should take precedence over ODF/Calc semantics. -- You are receiving this mail because: You are the assignee for the bug.
