The length of the abbreviated month name (like printed out by "date +%b") is not the same for every month.
While "ls -l" can handle this okay, in some programs, at least mail/mutt, file list goes bonkers.
Why not use these names instead?
This data comes from CLDR, and it seems to be *formally* correct as required by GOST (the full reference is "ГОСТ Р 7.0.12-2011 СИБИД. Библиографическая запись. Сокращение слов и словосочетаний. Общие требования и правила").
Looking at the history here, it was the way you suggest before we started to use CLDR data (i.e., pre-11.x), and as we seem to disagree with CLDR on a lot of other definitions in timedef, guess we could call this a regression and restore the historical abbreviations for ru_RU.UTF-8.
Or maybe to comply with the standard, leave them as they are, but pad them to the maximum width with spaces? I think that is also what strftime does for one-digit numbers?
Or I could open a report on mail/mutt instead because it is really invalid to expect such things to be fixed legth?
Sorry for the delay here. It looks like a lot of other locales have the same variable length for '+%b', so it would still make sense to bring this up with mutt developers.
I must admit that I was a bit spoiled by looking at linux and seeing the short versions as you suggested for ru_RU.UTF-8, but after checking other our locales, I'm not so sure about changing them all.
It also affects calendar(1).
In the way that on multiline calendar entries the date exceeds 1 tabstop and so the first line of the entry shifts to the right.
Mentioned this to Mutt authors but they instead suggest user-side crutches: