I can get UK/European date format if I select United States as my locale in 'Settings' and I get US date format if I select United Kingdom as my locale; i.e. it's the wrong way around. This ought to be a simple fix.

Decided to start my new project using Proton Sheets rather than LibreOffice Calc, Immediately run into this show-stopper - I 9/6/2014 shows backwards, which is entirely unmanageable. I know why but you have to remember, this isn't "just cosmetic" it's non-functional when dates that are valid when transposed are used.

Alright, I'm not the only one with this issue it seems :D Let's hope this gets implemented soon

Honestly, we should be able to represent dates however we want independent of our locale. Just because I live in the UK or the US doesn't mean I want to use anything other than ISO 8601...

It seems the new Locale settings option in Proton Sheets has the wrong date formats for at least some locales.

In File > Settings:

-- When I choose United States locale, the date format is dd/mm/yyyy dates but should be the opposite (mm/dd/yyyy)

-- When I choose United Kingdom locale, the date format is mm/dd/yyyy but should be dd/mm/yyyy (or whatever the standard is for UK)

It seems the correct date formats are switched for at least these 2 locales, maybe others. Please fix, this is a real deal breaker for Sheets and the reason I haven't been able to start moving over to Sheets. Otherwise though keep up all the great work Proton and love all the new products and features you have been rolling out.

Wait what -- I'm having the opposite problem of everyone else. I'm in the US and since day 1 when Sheets was released, my dates have been in Euro format (dd/mm/yyyy).

How do I get the mm/dd/yyy US format that everyone else is getting? I basically haven't started adopting Proton Sheets yet because of this deal breaker.

Better would be custom date formats allowing short day of week (e.g. Mon), filler zeros, unambiguous Jira style dates (i.e. 01-Jan-2026), etc. ISO 8601 is yyyy-mm-dd by the way not yyyy/mm/dd.

Documents should have setting for "language/locale" which would help setting up this kind of things.

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