Locale Issues with Month Name

[mcrossley]

The Mono version 5 release has thrown up an issue with some locales and the short month names.

They have changed the short month name (in English for example) from "Jan" to "Jan."

CMX uses the short month name to name the log files, and this change means that it can no longer find any of the existing files.

For example "Jan19log.txt" becomes "Jan.19log.txt"

As I see it there are a number of options:

1. Wait to see if the mono developers roll back these locale changes. In the meantime some CMX users cannot update to Mono 5.
2. Just go with it, users will have to rename their existing files to the new format. However that means the data files will not directly transferable for those users between Linux/macOS and Windows hosts.
3. Apply a "fix" to Cumulus MX that strips any "." characters from the short month in the filename. What I do not know here is if any users already use the "Jan." short month format in their locale. If they do then the "fix" will break Cumulus MX for them.

The more I look into locales the more confusing it gets. The Unicode organisation publishes extensive locale data, and many locales defined there do include a "." in the short month name - is the Mono group just implementing what they say, or ISO xxx? For "general" English according to Unicode the short month should be "Jan." but GB English uses "Jan". Who knows!

I guess option 3 may be favourite, but I need people to shout if that will break their installation.

Any thoughts.

[HansR]

Good! Thanks for addressing the issue.

My installation won't be broken, I have prevented the point in the filename when I discovered it, by not updating.
You ask for people to shout, but I am not sure all users are passing by here on the forum - usually only if they have a problem. So you may have an incomplete information situation here. I guess you must take it for granted that there will be installations which break and anticipate how to deal with it (see below).

1) As far as I have seen in messages on the forum, I guess there are already some users who use the 'Jan.' version of the filename but still not a huge amount. It may even be so that there are users who have never seen a filename without a point, depending when and how they started using Cumulus. However, if it is communicated well, it should be a one time action for those Cumulus users to concatenate the running files into one and to rename the existing files. After that, the filename system will never change again.

2) As far as the filename is concerned I would not be bothered too much with the Locale/Unicode. You might even consider to get rid of all locale related month names in the filename and simply use the English months without point, using your own string array while creating the filename and thus bypassing the whole locale system (you can't be certain the invariant version will NOT have a point). I would say that this would be my preferred choice. But it requires action for all NOT-en_GB users to actually concatenate the running file into one and rename all closed months (when the en_GB name differs from theirs) to the new naming convention.

If I oversee the problem well, I guess it is just making a choice for the filenaming such that no external influence can ever change it again - probably as close as possible to the existing situation - and actually communicate/warn the users very well of what is going on at the update which implements the solution. Give the users a prescribed procedure - maybe automated? - of what to do (which files must be renamed to what, which files must be concatenated).

And yes, no doubt that whatever choice is made, some users will suffer some work at the upgrade.
So the biggest thing here is to communicate and make the solution understood such that everybody on the forum can assist.

Let me know if I can do anything.

BTW: we recently had a documentary on emoticons, managed by the Unicode workgroup on Dutch television. That was interesting and it became clear that any change which needs the Unicode workgroup is in for a very long wait. Your option 1) may take a long time and even may never take place. It is beyond our reach.