Bug 232147

Summary: ru_RU.UTF-8: short month name length varies
Product: Base System Reporter: Michael Danilov <mike.d.ft402>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Only Me CC: yuripv, yuripv
Priority: ---    
Version: 11.2-RELEASE   
Hardware: Any   
OS: Any   

Description Michael Danilov 2018-10-10 07:42:31 UTC
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?
Comment 1 Yuri Pankov 2018-10-10 08:30:23 UTC
This data comes from CLDR, and it seems to be *formally* correct as required by GOST (the full reference is "ГОСТ Р 7.0.12-2011 СИБИД. Библиографическая запись. Сокращение слов и словосочетаний. Общие требования и правила").
Comment 2 Yuri Pankov 2018-10-10 09:10:09 UTC
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.
Comment 3 Michael Danilov 2018-10-10 11:54:40 UTC
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?
Comment 4 Michael Danilov 2018-10-10 12:24:29 UTC
Or I could open a report on mail/mutt instead because it is really invalid to expect such things to be fixed legth?
Comment 5 Yuri Pankov freebsd_committer 2018-10-28 00:08:39 UTC
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.
Comment 6 Michael Danilov 2019-01-04 14:34:40 UTC
It also affects calendar(1).
Comment 7 Michael Danilov 2019-01-04 14:35:22 UTC
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.
Comment 8 Michael Danilov 2019-01-20 22:54:31 UTC
Mentioned this to Mutt authors but they instead suggest user-side crutches: