RAD-2443: fix date location language issue

[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:

1) when date is like Nov-04-2022_111111

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

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

4) a not parsable format; for example: abc-99-9999_999999

[terrypacker]

Ok I see this is for the JSON backup, not the database backup. So the filename is being parsed and failing on line 231 of BackupWorkItem. I would suggest that any fix also considers that code. I still stand by my suggestion of making this configurable in the mango.properties and keeping the default format as it exists in the main branch so we don't break support for people who are currently expecting the backup filename format as is.

[terrypacker]

Also @juancarlosgl for your reference Mango can bet set to run in any locale manually as well as by detecting it via the JVM so if you want to reference the locale in use this is the code;

Common.getLocale()

[terrypacker]

@juancarlosgl perhaps you could use something like this when generating the date and parsing it, maybe the way the JVM formats and parses isn't the same?

To generate the date string:

new SimpleDateFormat(BACKUP_DATE_FORMAT, Common.getLocale()).format(new Date());

To parse it:

new SimpleDateFormat(BACKUP_DATE_FORMAT, Common.getLocale()).parse(lastRunDateString);

You could test that by setting your locale to Turkey

[terrypacker]

@juancarlosgl if all else fails I suggest you set your Locale to Turkey, Debug Mango and step through the parse logic in SimpleDateFormat and understand what is going wrong. Once we know that we can understand how to fix this.

[ManuelCalvo3Pillar]

@terrypacker I was speaking with Juan, and we thought a good idea could be to have 2 date formats: one internal date format used to store the last backup date in a string format that is never going to be affected the system locale (by removing month or days names) and another date format to be used by the backup file name (which can have month name, as it is right now). So in that way we can always parse the last backup date no matter which language is currently in use. What do you think about this?

[ManuelCalvo3Pillar]

@terrypacker also we were discussing this solution to address the problem of customers installations that are not currently using this language agnostic date format, which we think can be something like this: at startup it will try to parse the existing value stored in the database for the last backup date (stored in not language agnostic way) if not exception is thrown then it will replace with the internal new string generated using the new language agnostic format. If an exception is thrown the existing value in the database won't be updated (meaning is now using the new language agnostic format). The backup file names won't be affected as they will continue to use the existing date format.

[terrypacker]

@ManuelCalvo3Pillar I'd like to first understand what is going wrong with the parsing of the dates, it should work if both the date was generated and parsed in the same locale so I'm a little confused as to what is really happening.

Otherwise, if you do intend to update the database we have a mechanism for that with hooks to upgrade the DB and increment the version stored in the system settings.

Show me what code in SimpleDateFormat is actually failing and why before we go any further.

[ManuelCalvo3Pillar]

@terrypacker the problem is like this they initially had their Mango in English, the system stores in the DB the last backup date in a string format that has English months names in it. Then they changed the language to be Turkish. In some part of the code the system tries to parse the stored value (in English) as it is in the new language Turkish, the parse of it fails. That is why they are getting: “Unparseable date”.

[terrypacker]

Yeah ok that makes a lot more sense. Sounds like they could just delete the old backups or rename them? Why would we change any code?

[juancarlosgl]

Yeah ok that makes a lot more sense. Sounds like they could just delete the old backups or rename them? Why would we change any code?

well what it is causing issues it is the latest databaseBackupLastSuccessfulRun value stored in the database that must be in English and when backup runs tried to parse that date but due to the language it is not posible to go on, maybe it is easier to correct that date value instead of adding some code changes.

[terrypacker]

@juancarlosgl I see this change is for 4.3.x and that is why the build is failing because you don't have the same branch on all the repositories for Team City to check out.

I suggest that you make another PR for Main and use that as the first PR to get correct. Once that is done you can then merge the changes into 4.3.x

[juancarlosgl]

Closing this PR to follow Terry's suggestion. PR to main is this