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: https://gitlab.com/muttmua/mutt/issues/95