Default Date format YYYY.MM.DD

English
1

Hi,

I noticed that in one of the latest updates, CSV Importer has the default date format set to YYYY.MM.DD. Does this apply globally? Is it possible to change it? In my country (Slovakia), the default format is DD.MM.YYYY, so I have to change the date format every time before importing data.

Thank you for your help.

2

You can save the import configuration, then load it.

You can find small “tool” icon somewhere in the CSV Import window.

3

This issue has already been reported, as per - Default date format changed from DD.MM.YYYY to YYYY.MM.DD in CSV import (since 0.81.1) – data corruption risk · Issue #5365 · portfolio-performance/portfolio · GitHub and currently PP doesn’t feature a global setting for “preferred default date format”.

Hopefully this will be fixed soon :crossed_fingers:. In the interim, once you’ve set the correct format and mappings for one file, use the gear icon in the CSV importer to save that configuration. Next time you import a similar CSV, you can select your saved template — including your chosen date format — so you don’t have to change it each time.

1 Like
4

I doubt a fix here. First, it was set intentionally. Second, date formats are different. Changing to whatever never satisfies all users.

And as u said, save a template and import from there.

5

Where is the format yyyy.MM.dd used in real life? I have never seen that out there, yyyy-MM-dd on the other hand
 :wink:

6
7

China Date Formats

8

That’s yyyy-MM-dd, not yyyy.MM.dd.

1 Like
9

China Date Formats
In China, dates are typically written in the year-month-day (YYYY-MM-DD) format, following the ISO 8601 standard. Traditional Chinese formats also include year, month, and day characters

Alternative format using dots (YYYY.MM.DD).
Common Usage: Some business contexts

1 Like
10

No it’s not only “-”.

See:
Als Beispiel seien hier verschiedene lĂ€nderspezifische Schreibweisen fĂŒr den 2. April 2008 (2008-04-02) genannt: 2/4/08, 4/2/08, 08/4/2, 4/2/2008 sowie Variationen mit . oder - statt / .

11

This format was added rather recently, but I do not think the intention was that it becomes the default format.

12

Please correct me if I’m wrong, neither in the mentioned PR nor the CSV wizzard are defaults maintained.

13

Thanks for sharing your perspective @Sn1kk3r5! I fully appreciate that date formats vary globally. My concern is less about changing the default arbitrarily and more about the impact on users, where imports may now misinterpret dates and cause errors.

The actual problem reported in Issue #5365 is Incorrect Date Parsing. After updating to version 0.81.1, importing a CSV with dates like 01.05.2025 results in those dates being interpreted as yyyy.MM.dd instead of dd.MM.yyyy. In other words: a European formatted date (1 May 2025) is mistakenly treated as a year‑first format (Year 01, Month 05, Day 2025), which is nonsensical and corrupts the data.

Incidentally @Sn1kk3r5, in the UK we use ‘DD/MM/YYYY’. I think you may have made about point about ‘/’ versus ‘.’, which perhaps I ought to appreicate, but I don’t understand German - this is the English section of the forum :grinning_face: !

14

The link is available in 49 languages. The reason I pasted one German sentence: @Kimmerin overlooked the part I pasted here, and I know he speaks german.

Regarding:

I get your point, but software can never please every user
 how about the others, which failed in the past?

The format can still be changed and saved for further csv imports.

15

Thanks for your perspective. I understand that software can’t satisfy every user, and that other formats have had issues before. My concern here is that this isn’t just a preference issue—it’s causing incorrect dates to be imported, which can silently corrupt users’ transaction histories. That’s a data integrity problem, not a cosmetic choice. Perhaps we could discuss ways to maintain backwards compatibility or let users explicitly select the format to avoid this kind of silent misparsing.

16

I think the importer tries to “guess” the default format based on the first data point in the CSV file. It iterates over the formats and the first one that produces a date, is defaulted. Maybe that changed?

17

Thanks for the clarification @AndreasB. That helps me understand what’s happening. It sounds like the importer “guesses” the date format based on the first row and uses the first format that successfully parses a date. With the addition of yyyy.MM.dd, that may now be matched first, which can misinterpret dates like 01.05.2025.

The issue here isn’t just preference — it can cause incorrect dates to be imported, silently corrupting transaction history. Maybe the importer could either let users explicitly select the format for ambiguous cases, or prioritize historically common formats like dd.MM.yyyy in locales that use them. Even a warning when a date is ambiguous could prevent data errors while keeping the new format support.

18

Yes it is :wink:

An example for what. you ask? The answer is in the sentence right before your quoted part:

The part you’ve quoted lists examples of other locale-specific formats, not ISO 8601.

19

You have not experienced ISO standards until you have read them in the original Klingon. :wink:

20

As mentioned above yyyy.MM.dd is no date format that is out there and I hope @Sn1kk3r5 now came to the same conclusion after I’ve explained the meaning of the paragraph in the Wiki-article :wink: So this template can be removed from the list of attempted templates.

Not here to brag but in terms of knowledge about data formats out there and the date formats being used I think I’m in the TOP 3 in this forum. :wink: