Docker entrypoint improvements

[pizkaz]

• Switches the interpreter to /bin/bash. Rationale: bash is installed anyway, so we might as well use it. This also allows us to use local and other bash features.
• Enables -o pipefail. Rationale: It is best practice to do so.
• Fixes shellcheck false-positives.
• Fixes whitespace issues (spaces at EOL, tabs instead of spaces).

Fixes #2428

[tmh-grunwald-markus]

I'm using Chromium Version 133.0.6943.126 (Official Build) built on Debian GNU/Linux 12 (bookworm) (64-bit) and have exactly the same error.

[ghnp5]

Came here to report the same :)

Just set my locale to "Portuguese (Portugal)" (pt_PT), and the date format for new events is still MM/DD/YYYY, instead of DD/MM/YYYY.

Thanks!

[GK-774]

It´s not just Firefox, same effect with Edge. Setting the Locale (German (Austria) in my case) just does nothing, the date format remains at MM/DD/YYYY as already mentioned by ghnp5. Even in the profile the birth date remains at MM/DD/YYYY when changing the locale. There should be a setting for the date and time format independent of the locale anyway.

[ChristophWurst]

Thank you for your feedback.

[astehlik]

Not sure if this is the same issue but for me setting intl.regional_prefs.use_os_locales to true in Firefox in about:config did help as described here: https://superuser.com/a/1804828/1110585 (my system locale ist set to de_DE.UTF-8)

[TasPats]

setting intl.regional_prefs.use_os_locales to true in Firefox in about:config

helps immediately

[GK-774]

Thats not a solution. If I set a date and time format in Nextcloud this and only this shall be the format which is used no matter which browser I use. If I do not set a date and time format it should default to ISO 8601.

[moepman]

I just wanted to highlight that it also broken in chromium

[rostwald]

Same here on different browsers and OS.

Setting intl.regional_prefs.use_os_locales does not help. Setting 'default_locale' does not fix it, neither does 'default_language'.

Please, NEVER use any automation for something the USER EXPLICITLY DEFINED WHAT HE WANTS TO USE! Especially if the automation is broken anyways... This (unwanted) automation creates all sorts of other problems, even if it would work as intended: I live near the DE/AT border, so my phone regularly uses the cell network from AT, which already lead to a complete chaos of "Europe/Berlin" and "Europe/Vienna" Timezones in recently added events. I also use several systems that use the en_US locale/language (but with the sane ISO8601 date and 24h format, which should ALWAYS be the default fallback), but I'd NEVER want this to propagate into my calendar in any way.

And seriously - don't blame a regression/misfeature on the browser; especially if reports show that the unwanted behaviour is present in all browsers...

If it is that hard to fix this (i.e. make it an opt-in (!!) to use automatic locale/timezone selection), pelease just revert the commit that changed the correct behavior in the first place (i.e. #6423 ), but it's been over 2 months now without a fix...

[ChristophWurst]

Thank you for your feedback

[Redsandro]

I migrated from Nextcloud 27 (iirc) to Nextcloud 31 and this issue is back. I don't know how I fixed it a few years ago, but considering the below quote, the problem is probably a different one this time around if I understand correctly.

With #6423 we replaced the custom (and buggy) datepicker with a native one. The objectives were usability and accessibility.

I don't mind a temporary hack to stop the complaints of the users of the instances I manage. :) But a server side one, I can't tell everyone to fix their browser if it used to work for them.

BTW I'm personally using a Chromium-based browser, not Firefox. And I see the problem too.

[daniil-berg]

TL;DR

The locale I set in my Nexcloud profile is the only one that should be considered everywhere in the UI. Not any browser or system locale.

---

Maybe I am misunderstanding, but it seems as though the date/time picker in the event modal is now intentionally ignoring the locale settings of the user and instead relies the browser language/locale setting? @ChristophWurst I hope I got this right.

With all due respect, why on earth would a user facing application that has its own locale setting NOT make use of that setting in any instance?

Maybe I don't want to change the language of my browser (English/US), but I still want my Nextcloud to display dates/times consistent with the locale I set there (German).

If this is not possible with the new "native" datepicker, please consider reverting back to the custom one. The fact that it has bugs in its implementation is not a reason to abandon it. Especially if that comes at the cost of consistent locale display.

I am a big fan of the project and I am thankful for all the work that goes into it.

[ChristophWurst]

We will switch back from the native picker to a custom picker with the upgrade of @nextcloud/vue v9. It comes with a replacement for the old deprecated and inaccessible time picker, and works with the Nextcloud locale setting. I can't give a specific ETA, but this is our plan. Thanks for the input everyone and apologies for the inconveniences.

[voidzero]

mm/dd/yyyy is the biggest annoyance imho. It's fine when you have 31 october show up as 10/31/2025 because a non-american will just go 'meh' but there are many instances where this is not visible. 6/6/2025? Good luck.