RAD-2443: Fix Language Parse Issue 4 scenarios

[juancarlosgl]

Ticket RAD-2443 where it is reported that when backup process is running and when backup file name is built when getting the current date it is happening an issue as current system date is like:

Kas-04-2022_111111

so as the month is in Turkish when it is trying to format that date to the following format:

MMM-dd-yyyy_HHmmss

the following exception happened as it is trying to load that date as an English date:

java.text.ParseException: Unparseable date: "04 Kas 2022"

Solution: We will store last execution date as a Long but on a String field.

so now we will face 4 posible scenarios:

when date is like Nov-04-2022_111111

when date is like 1699414888000 (stored as a long into an String)

when date is in any laguage different from the system; for example: Kas-07-2023_214128

a not parsable format; for example: abc-99-9999_999999 this last one never should happen as dates are created by our system.

[juancarlosgl]

This fix also applies to this PR for ma-modules-proprietary.

[jazdw]

when date is like 1699414888000 (stored as a long into an String)

Why not store the date as an ISO-8601 with UTZ zone rather than an epoch timestamp? Makes it more readable if it is going to be a string anyway.

[terrypacker]

@juancarlosgl Jared makes a good point. I know we agreed upon ms since epoch but using UTC (Z) timezone is much better if someone wants to manually edit that value in the system settings table.

[jazdw]

@terrypacker Honestly I don't know why we are using locales for dates at all in this scenario, we should just use a standardized format everywhere (except for backwards compatibility).

[juancarlosgl]

closed as document Procedure to repair Mango installation when backups start failing as language is changed was created as mention in the discussion on the Ticket RAD-2443.