From: Stuart Henderson Subject: Re: tog add century To: Tracey Emery , gameoftrees@openbsd.org Date: Tue, 3 Dec 2019 12:45:36 +0000 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 :-/ > > > > 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! 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. > 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.