Mailinabox: Use international date format

[ad-si]

I'm getting email notifications like:

✓  TLS (SSL) certificate is signed & valid. The certificate expires on 01/04/21.

Please change it to

✓  TLS (SSL) certificate is signed & valid. The certificate expires on 2021-04-01.

Or is it 2021-01-04? 😭

[ddavness]

The date format is not hardcoded, as it uses the format of the locale set for the machine.

The issue here is that we use the en_US.UTF-8 locale. In theory you could use any UTF-8 locale in the machine and the daemon would still work, but I'm not sure how to:

1. Actually making the daemon recognize the new locale;
2. Not reverting to en_US when upgrading.

I might investigate this and eventually submit a relevant PR.

Edit: The date you're seeing is 2021-01-04

[ddavness]

Ok so here's a workaround you can use for now:

1. Generate the locale you want. For the ISO date format YYYY-MM-DD, we can use en_DK.UTF-8:

sudo locale-gen en_DK.UTF-8

You can use the locale you're most comfortable with (e.g. pt_PT for DD/MM/YYYY)

1. Set the locale in the daemon. You'll need to edit the daemon's entry point (daemon.py) which is on your local repository.
2. If you used the bootstrap URL then this repository is located in /root/mailinabox

$ sudo vim /root/mailinabox/management/daemon.py

And then add these two lines near the start of the script

import locale
locale.setlocale(locale.LC_TIME, "en_DK.UTF-8")

1. Restart the daemon!

sudo service mailinabox restart

[ad-si]

To be honest, in this scenario I'd hardcode it. I don't know of a single sysadmin who'd prefer the format from the locale over the unambiguous ISO8601 in a server setting. And even if, they shouldn't.

If this is too oppressive for you, I'd rather provide extra settings for the format. The locale system is broken beyond repair. Some combinations just don't exist. E.g. my preferred settings are:

• 24 hour time
• YYYY-MM-DD
• thinspace as thousands separator
• . as decimal point
• Monday as first day of the week
• Temperature in C°
• ...

Also having an obscure locale might have all kind of unwanted side effects because software suddenly starts to behave like you're in Denmark for real.

[ddavness]

To be honest, in this scenario I'd hardcode it. I don't know of a single sysadmin who'd prefer the format from the locale over the unambiguous ISO8601 in a server setting. And even if, they shouldn't.

cc @JoshData

I do prefer ISO over middle-endian dates too - but disagree with hardcoding it: after all, not everyone is a sysadmin, or some people simply have different preferences. We can make everyone happy!

The locale system is broken beyond repair. Some combinations just don't exist.
(...)
Also having an obscure locale might have all kind of unwanted side effects because software suddenly starts to behave like you're in Denmark for real.

Fortunately, and if locales work like I think they work - you don't need to stick with a single locale for everything. You can, for example, use fr_FR.UTF-8 for the time and ja_JP.UTF-8 for the language. In this case, notice how we're only setting LC_TIME - it means everything else (language, paper formats, etc. if it was applicable) will remain as-is.

---

As you exactly said - The route of asking for a locale/time format at setup time (IIRC the time/date format is the only thing in the admin panel that depends on a locale, someone correct me if otherwise), seems like the least disruptive option, or at least reacting to some environment variable. But I'd like more feedback (particularly from the maintainers aka Josh) before anyone starts doing any kind of work.

[JoshData]

I'm not really interested in making everyone happy. I just want it to work for everyone easily. So I am fine hard-coding the ISO format YYYY-MM-DD.

[ddavness]

Then... So be it, I guess. 🤷‍♂️