Changelog

odoo/o-spreadsheet#5943

Created by BI, Lucas Lefèvre (lul)

Blocked

label
odoo:master-bye-date-strings-lul
head
7930e9f5b9093571264679a8d6ab9a45ebddd8c7
odoo/o-spreadsheet
master #5943 missing r+

[IMP] pivot: insert pivot with real date

Purpose

Currently, when you group a pivot by day and insert it in a spreadsheet, the generated pivot functions look like

=PIVOT.VALUE(2,"amount_total","date_order:day","06/01/2023")

"06/01/2023" is ambiguous. Is it the 6th January 2023 or the 1st June 2023 ? It turns out it's always interpreted as a US date (mm/dd/yyyy): 1st June 2023. Even if the spreadsheet locale is FR (dd/mm/yyyy). If the locale is FR, it's inconsistent then: if you type "06/01/2023" in a cell, it's interpreted with the FR locale as 6th January 2023, but specifically in PIVOT functions, it's interpreted as 1st June 2023. The reason is historic: before the introduction of locales, everything was US, always. When we introduced locales, we left the way it was interpreted in PIVOT functions to avoid breaking existing spreadsheet when changing the locale)

Alternatives

  • Interpret the string in PIVOT functions with the spreadsheet locale. This is a breaking change though. We could upgrade spreadsheets for simple cases, but not if the date comes from a reference to another cell, with an arbitrary complex construction with functions. Changing the locale would also break all pivots with hard-coded date string.
  • Support only "real" dates in PIVOT functions (DATE(2023, 6, 1) instead of the hardcoded strings). It means no more ambiguity and no inconsistencies anymore. But it's a breaking change and we can't upgrade all existing spreadsheets (same issue as above). The benefit compared to the alternative above is that dates that we would not be properly upgraded would now result in errors, allowing the user to spot the issue and fix it.
  • Insert functions with string dates with the year first "2023/06/01". Those dates are always interpreted as yyyy/mm/dd which makes them unambiguous, no matter the spreadsheet locale. If the user manually types a PIVOT function with "06/01/2023", we keep the current behavior and interpret it has US. This ensure there's no breaking change.
  • Same as above but insert functions with DATE(2023, 6, 1). Preserve the current behavior and interpret hard-coded date strings as US.

The last two options are preferred to avoid any breaking change. We choose the last one to encourage users to use DATE(...) and avoid hard-coded date strings in formulas, which don't work well when changing the spreadsheet locale.

task-3973659

Description:

description of this task, what is implemented and why it is implemented that way.

Task: TASK_ID

review checklist

  • [ ] feature is organized in plugin, or UI components
  • [ ] support of duplicate sheet (deep copy)
  • [ ] in model/core: ranges are Range object, and can be adapted (adaptRanges)
  • [ ] in model/UI: ranges are strings (to show the user)
  • [ ] undo-able commands (uses this.history.update)
  • [ ] multiuser-able commands (has inverse commands and transformations where needed)
  • [ ] new/updated/removed commands are documented
  • [ ] exportable in excel
  • [ ] translations (_t("qmsdf %s", abc))
  • [ ] unit tested
  • [ ] clean commented code
  • [ ] track breaking changes
  • [ ] doc is rebuild (npm run doc)
  • [ ] status is correct in Odoo