Store Unix Time instead of ISO formatted string

Currently, we store datetime as an ISO formatted string (for example, "2022-03-23 20:58:40.584444").

This has the advantage of being human-readable. However, this comes with the big disadvantage that we don’t know what timezone we’re talking about. This leads to various problems. For example, when global users are updating documents. Or when the backend updates documents before and after the system timezone changes.

Some of these issues have been addressed already, for example, by trying to convert to and from the users’ timezone. However, the underlying issue remains: we’re storing times without the timezone.

A nice solution would be to store the Unix Time or UTC timestamp. (The unix time would also make comparing and calculating with times easy – after all, it’s just a number.) When we need to display the timestamp, we can convert it to the appropriate timezone.

Existing time stamps could be assumed to be in the timezone from System Settings, before conversion.

• https://mariadb.com/kb/en/datetime/
• https://www.postgresql.org/docs/current/datatype-datetime.html

[hrwX]

@barredterra @ankush

• #13504 This PR kinda does the same, all the timezone in the database is stored in the default timezone, which is set during the setup, and then that field in system settings is read-only.
• So if we have to keep the db in UTC, we just have to set UTC in System Settings, and it’ll just work!
• But we cannot patch the existing system.
• FYI this change was introduced since it fixes the issue of having multiple timezones in the db for multi-company/multi-country setup

[ankush]

We can modify the scheduler’s timezone to some other configured value if that’s only roadblocker. It’s a very localized changed in scheduler.py

It’s better to keep scheduler in local timezone because ERPNext has few events which are best triggered at midnight (imagine birthday reminders, would be weird af to receive them 5 hours before that day starts 😄)