From: Tracey Emery Subject: Re: tog add century To: Stuart Henderson Cc: gameoftrees@openbsd.org Date: Tue, 3 Dec 2019 08:02:54 -0700 On Tue, Dec 03, 2019 at 12:45:36PM +0000, Stuart Henderson wrote: > On 2019/12/03 13:36, Stefan Sperling wrote: > > On Tue, Dec 03, 2019 at 12:24:20PM +0000, Stuart Henderson wrote: > > > On 2019/12/03 12:14, Stefan Sperling wrote: > > > > On Mon, Dec 02, 2019 at 10:33:37AM -0700, Tracey Emery wrote: > > > > > Hello, > > > > > > > > > > I just noticed that tog doesn't display the century on the year, either. > > > > > This diff adds two spaces to the date column and adds the century. > > > > > > > > > > This format change is to match the century change to got blame, if > > > > > anyone is interested. Perhaps I'm the only one that cringes when I see a > > > > > year without the century. > > > > > > > > > > It also adds a tab after TOG_COLOR_DATE to align the 11 with the rest of > > > > > the defines in that block. > > > > > > > > I decided to use two digits for the year to save space on narrow terminals. > > > > I'm really sorry for people from countries where MDY ordering is in use :-/ Yuck. But, it's a good lesson for me to remember what other country defaults are, no matter how hideous. As a quick poll, what are the narrowest terminals people are still using? Are there still 80 col users, or less? As I play with various widths, I went down to 80 columns, to fit style(9), and tog is still quite readable to me, even with the two /'s. It would be interesting to see screenies from various people, although that seems rather infeasable. > > > > > > How about YYYYMMDD without the /? > > > > Would it be obvious that such a number is supposed to represent a date? > > It would to me (especially with the full year), but possibly not everyone! It would be to me as well. However, that comes from a lot of database and archiving work where the chronological ordering of the format is automatic. > > I've just realised that I currently have YYMMDD (no /) for my date string > in mutt's header list and I parse that easily. I think perhaps tog's current > format tricks me because UK short-form dates are normally written as > either DD/MM/YY or DD-MM-YY so the / acts as a cue. > > > > I don't think it's too bad for MDY countries, most of the displayed > > > YY/MM/DD dates are invalid at a quick glance. Coming from DMY-land many > > > of them are potentially valid so more mental effort is needed. > > > > I also figured that it would be obvious. But this is not the first > > time a change to the current format has been requested on grounds that > > it is confusing. Artturi Alm did suggest to use DD/MM/YY instead, > > but I doubt that would actually solve anything. > > > > > > Could we make the number of year digits depend on the width of the screen? > > > > Similarly to how we do it for the commit ID column? > > > > > > That would work too. Aye. > > > > An alternative would be to use a strftime string from the environment, but > then it's awkward to figure out a column width with some of the possible > formats. Perhaps! Perhaps, I should just get accustom to YY/MM/DD. -- Tracey Emery