These excel-line functions use ';' to delimit parameters, you've used ','. See what the documentation.
post
The reference date (the date that 0 represents) is not set as you expect. This happened to me when I imported Numbers files into LibreOffice Calc and is the reason I know about this at all.
The reference date (the date that 0 represents) is not set as you expect.
It is not clear to me what this means. But my data was typed in rather than imported from somewhere else if that matters.
I don't remember what LibreOffice calls it, but there is an option to choose which dates are the starting points for counting, so that 0 corresponds to different dates for reasons of compatibility with other spreadsheet systems. Yours is not set to what you're expecting.
One of the options is 4 years 1 day later than the LibreOffice standard, which explains why those dates are off by that much.
There is a setting per workbook and possibly a global setting that would affect all new workbooks until you change it.
Search the web for something like "1904 date option LibreOffice Calc" and you'll find out the details. Good luck.
Libre Office Version and OS?
I seemed to have solved my problem by adding spaces in the function as such =func(x, y, z). It is not clear to me why that matters, but I guess.
Version: 25.2.5.2 (X86_64) / LibreOffice Community
Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded
Me: Oh, I've been bitten by something like that in code, I bet it's a subtle timezone issue where applying the current timezone to the 00:00:00-timestamped datetime encoding of the date, and then truncating it back to the date only, winds up shifting...
Me, after reading: What the FUCK, why
all 2 comments