Because we are used to the european layout which uses in certain numbers in e. g. , instead of .
This would make things so much easier, especially when importing existing excel calcs to proton.

One can select (on a sheet base), a "locale" (missing for instance Belgium as option), which then determines the datum format for _all_ datum items in the sheet.
A "individual cell datum" format would be more usefull (in my case even conditio sine qua non).

My personal need is to have at least both : ISO8601 (YYYYmmdd["T"HHMMSS])
and dd/mm/yyyy

Currently, Proton Sheets defaults to US date formats. This makes the Calendar Picker and Data Validation unusable for European users. When a date like "20/03/2026" is entered, the system treats it as plain text instead of a date, breaking the chronological sorting and the double-click calendar functionality. We need a "Locale" setting to support international standards.

Can some consideration can be allocated to the request of Date format? Not everyone considers that a date with this format make ANY sense 2/4/2026

Is it 2nd April 2026? Is it February 4th 2026?

We need Proton to acknowledge that ISO defines date formats.
2026-04-02

https://fr.wikipedia.org/wiki/ISO_8601#/media/Fichier:ISO_8601_explanation.svg

DD/MM/YYYY is **essential**

Being locked into mm/dd/yyyy makes Proton Sheets hard to use outside the US. It’s not just inconvenient — it creates confusion and errors.

At minimum, we need:

dd/mm/yyyy (global standard)

For an international product like Proton, this isn’t optional — it’s essential.

I understand that if you need to start with just one date format, it makes sense to consider the US, which likely represents the largest user base—probably by a significant margin. From a business perspective, it’s logical to adopt their date format from the outset. However, date formats can be a sensitive issue for those of us living outside the US. I acknowledge that countries like Canada may not have a large enough population on their own, but the second most commonly used date format is dd/mm/yyyy. Many countries, when combined, likely approach the US population size. I trust that you will begin developing a solution that uses the US date format as the default while still allowing users to choose from a variety of formats.

Definitely needs to have dd.mm.yyyy!

Just signed up, so I can back this. This is important!

Yes to this - it is mucking up my spreadsheets - I find it bizarre that a company based in Switzerland is using the US format which isn't used outside of the US!
Please, please fix it!

Unusable for me without dd/mm/yyyy.

And please don't forget dd.mm.yyyy

Financial is also an issue. Defaults to USD and different ways to display those values. Euro is an afterthought under the very limited "Other currency" option. I do not need USD just like I don't need US dates, times notation.

Ironically I'm having the opposite issue: American getting the global format.

Formatting hours is a really useful option to me. However, being stuck with the AM/PM formatting is really annoying, especially considering that the 24h format is used in a lot of countries and is even the ISO 8601...
In short I would love to see the option in the formatting... The strangest thing is that it is available when using the date&hour format... Please be consistent and give the user the choice on the formatting they want to use :)

Also see this more general localization idea: https://protonmail.uservoice.com/forums/932839-proton-drive/suggestions/50795321-location-settings-for-sheets-date-numbers-curr
Also covers numbers/currency.

Totally agree. As a European, my brain doesn't compute the month-day-year format we're stuck with now.

Yeah unusable without this feature, also need to not default to USD

Need that feature too. Not usable without german date formatting. (dd.mm.yyyy)

This, plus date using dots instead of slashes, with the full month number instead of dd/m/yyyy when the month is a single digit!

Also, more options for other formats such as numbers – it's absurd to force the American comma as thousand separator and dot as decimal separator. I'm not going to use this until different formats are available.