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