|Summary:||ru_RU.UTF-8: short month name length varies|
|Product:||Base System||Reporter:||Michael Danilov <mike.d.ft402>|
|Component:||misc||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Only Me||CC:||yuripv, yuripv|
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 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.