mcrossley wrote: ↑Thu 17 Oct 2019 2:39 pm
I disagree, [...]
OK, agree, we disagree.
Apparently it is a problem, locale related, which has occurred more or less often in the past and the problem seems to be outside Cumulus, but in the control of the user.
mcrossley wrote: ↑Thu 17 Oct 2019 2:39 pm
Lots of countries use a dot and space as a separator, so short dates may be something like "d. m. yyyy"
Yes, but that is irrelevant.
The short month format ('MMM') - used by Cumulus - never has a point or at least I have never seen one (I haven't seen a spec either).
The information we get out of the MS system, after reporting the bug, is mscorlib. Your believe may be worth something, for me it is the info I get from MS. Besides that, since MS has become partner in Mono, you may assume (yes, assume, not sure) that there will be shared code. If not, software of that size and complexity becomes unmaintainable. But that means that bugs/changes also will appear at strange places.
mcrossley wrote: ↑Thu 17 Oct 2019 2:39 pm
As far as I can see lots of issues flagged mscorlib are actually problems in the mono code.
If Windows had started to randomly change date/time formats I'm pretty sure other people would be shouting about it.
We are guessing, yes so am I. But
randomly changing? And how many programs would use the date as the basis for a filename?
mcrossley wrote: ↑Thu 17 Oct 2019 2:39 pm
Is what Cumulus uses to store data and name files ideal - far from it, Steve said he would never have designed it like it is if he knew so many people would use it - it was originally designed for his personal use. You would use ISO date formats, and dot decimals etc. But with a large installed base you cannot easily change it now.
Version 4 of CMX - if it ever sees the light of day - will use the Invariant Culture internally and for all data storage, just converting to user locale for display purposes. It would be provided with a conversion utility to perform a one-off conversion of historic data to the any new formats.
I know how Cumulus forms it's name and I truly believe Steve would never do it again like that. But here we are, this is how it works. And OK, forget about C1 because it is not possible to change that code. But CMX is possible. And very easy. So there is a workaround to solve this problem and eliminate the environment and the user.
Cumulus creates the filename like this:
Code: Select all
var datestring = logfiledate.ToString("MMMyy");
return Datapath + datestring + "log.txt";
You can use the formatting with the CultureInfo.InvariantCulture there (and leave everything else untouched) and see if it really solves anything (I think it will). Or, because the abbreviation will probably differ in different langages, either search for the point and remove it (best for keeping the current month abbreviations) or you can use the logfiledate.Month as an index to your own array with month names. Easy and problem solved and independent of any failing date/locale system. I don't see the problem.
As it stands now, I - and not only me - can not upgrade the OS/Mono because of loss of data (as this user describes), we have seen many reports on this. You don't even have a planning for version 4. Don't be idealistic, you say yourself
if ever, this is workaround which takes less than half an hour, maybe a bit more if there are more places where a filename is formed like this.
Just give it a workaround so we can continue and leave this filenaming issue behind us even if it's not for C1 (In future I will better look which board a message is in).
It can't be that hard and I do not understand why it is not done.