Bug 170355 - Any date format other than MM/DD/YYYY won't allow auto-filliing based on the first few dates
Summary: Any date format other than MM/DD/YYYY won't allow auto-filliing based on the ...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.7.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-15 13:17 UTC by nathan.a.poole@gmail.com
Modified: 2026-01-16 03:31 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nathan.a.poole@gmail.com 2026-01-15 13:17:14 UTC
Description:
If I explicitly formt a column as date, and enter DD/MM/YYYY (Australian) date format, no amount of manually adding extra rows of incremented dates will make it xtrapolate past the first date entereted, just like it was text.

If I just type in 2 sequential MM/DD/YYYY or YYYY/MM/DD date rows, apply no fortmatting, select both rows, and autofil using the lower right handle, it just works.. Un predictable and kind of unuseable.

The only problem with YYYY/MM/DD is that the day just keeps incrementing past the end of month!

Autofill YYYY/MM/DD.. No upper range on day)
2025/11/19
2025/11/20
2025/11/21
2025/11/22
2025/11/23
2025/11/24
2025/11/25
2025/11/26
2025/11/27
2025/11/28
2025/11/29
2025/11/30
2025/11/31
2025/11/32
2025/11/33
2025/11/34
2025/11/35
2025/11/36
2025/11/37
...

Steps to Reproduce:
1. Enter two or more rows of DD/MM/YYYY data, with second date later htan the first
2. Format column/area as Date (or not.. it makes no difference)
3. Use right bottom handle that you normally use to auto-fill series of data, and only the first row will be propagated.. Whereas MM/DD/YYYY and YYYY/MM/DD work fine

Actual Results:
Manually typed to start series	Try to auto file	Autofill numeric	Autofill MM/DD/YYYY	Autofill YYYY.. No upper range on day)
19/11/2025	19/11/2025	1	01/01/26	2025/11/19
20/11/2025	19/11/2025	2	02/01/26	2025/11/20
21/11/2025	19/11/2025	3	03/01/26	2025/11/21
	19/11/2025	4	04/01/26	2025/11/22
	19/11/2025	5	05/01/26	2025/11/23
	19/11/2025	6	06/01/26	2025/11/24
	19/11/2025	7	07/01/26	2025/11/25
	19/11/2025	8	08/01/26	2025/11/26
		9	09/01/26	2025/11/27
		10	10/01/26	2025/11/28
		11	11/01/26	2025/11/29
		12	12/01/26	2025/11/30
		13	01/01/27	2025/11/31
		14	02/01/27	2025/11/32
		15	03/01/27	2025/11/33
		16	04/01/27	2025/11/34
		17	05/01/27	2025/11/35


Expected Results:
Sequential numbers based on initial rows


Reproducible: Always


User Profile Reset: No

Additional Info:
The same as it has done for 20 years
Comment 1 nathan.a.poole@gmail.com 2026-01-15 14:00:04 UTC
NOTE That when I create the desired document in Google docs, export/save as .ods to local drive, open it in Libre Calc, and select the last 2 rows of a column, and auto-fil with the handle, it works just fine
Comment 2 Regina Henschel 2026-01-15 20:36:31 UTC
(In reply to nathan.a.poole@gmail.com from comment #0)
> Steps to Reproduce:
> 1. Enter two or more rows of DD/MM/YYYY data, with second date later htan
> the first
> 2. Format column/area as Date (or not.. it makes no difference)

Wrong order. First format the column and then enter the date values. Make sure that the locale is correct, when setting the number format. That way you are sure, that the input is detected as date. Otherwise it depends on the global settings of locale and date acceptance patterns.

Drag-filling work for me in Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded
Comment 3 nathan.a.poole@gmail.com 2026-01-16 03:31:50 UTC
Thanks for the reply, Regina. Firstly, I had tried the format first, add data later, I but that wasn't the problem

My system locale settings weren't set (my TZ is Asia/GMT+7, but everything else is Australian)

on Ubuntu, setting locale to LANG=en_AU.UTF-8 with update-locale and rebooting gave me:

box:~$ locale
LANG=en_AU.UTF-8
LANGUAGE=
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=

This worked when I logged back in, created a document, formatted the col as date first as you said, and added some AU dates, and the autofilled.. The only thing was that I had to set the cell format to a custom DD/MM/YYYY format, otherwise, in spite of entering DD/MM/YYYY data, it defaulted to DD/MM/YY.. But after finding/remembering how to set a custom date format, it worked

For YYYY/MM/DD, I had to also add a custom YYYY/MM/DD format for that to work (there was a YYY-MMM-DD there already, but I wanted / separator)... This worked, and also stopped the runaway day part going past the month boundary, being now treated as a date

I also added "D/M/Y;Y/M/D" to the date acceptance default which only included "M/D/Y;M/D" (these perhaps should be included by default seeing users from all over the world use he software?) through Tools->Options->Languages and locales->General->Date acceptance patterns.. Also added Formats->Locale setting in the same place to "Default English (Australian)".. I'm not sure this was strictly necessary, but I assume it would have made things confusing, but would have been good to test both. But for sompleteness that looks tidier I guess

So setting the system locale properly worked, and I in an Asian TZ with AU locale defaults working basically perfectly now.. but there were several other steps in the program to make it complete

But both date formats work with the above steps now thanks. Hope this helps someone else at some point