"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: tog add century
To:
Tracey Emery <tracey@traceyemery.net>, gameoftrees@openbsd.org
Date:
Tue, 3 Dec 2019 12:45:36 +0000

Download raw body.

Thread
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.