user/dev discussion of public-inbox itself
 help / color / Atom feed
* [Patch] Update 24-hour times to use two digits for the hour
@ 2020-06-05 20:22 Varun Varada
  2020-06-05 22:03 ` Eric Wong
  0 siblings, 1 reply; 7+ messages in thread
From: Varun Varada @ 2020-06-05 20:22 UTC (permalink / raw)
  To: meta

Hello,

Here is a patch to update the timestamps displayed to have 2 digits
for the hour when since it is using the 24-hour clock:

diff --git a/lib/PublicInbox/View.pm b/lib/PublicInbox/View.pm
index 0bc2b06e..def138c6 100644
--- a/lib/PublicInbox/View.pm
+++ b/lib/PublicInbox/View.pm
@@ -178,7 +178,7 @@ sub nr_to_s ($$$) {
 }

 # human-friendly format
-sub fmt_ts ($) { strftime('%Y-%m-%d %k:%M', gmtime($_[0])) }
+sub fmt_ts ($) { strftime('%Y-%m-%d %H:%M', gmtime($_[0])) }

 # Displays the text of of the message for /$INBOX/$MSGID/[Tt]/ endpoint
 # this is already inside a <pre>
diff --git a/lib/PublicInbox/WwwStatic.pm b/lib/PublicInbox/WwwStatic.pm
index 3c933156..c3b29c49 100644
--- a/lib/PublicInbox/WwwStatic.pm
+++ b/lib/PublicInbox/WwwStatic.pm
@@ -294,12 +294,12 @@ sub dir_response ($$$) {
  } else {
  next;
  }
- # 54 = 80 - (SP length(strftime(%Y-%m-%d %k:%M)) SP human_size)
+ # 54 = 80 - (SP length(strftime(%Y-%m-%d %H:%M)) SP human_size)
  $hsize = sprintf('% 8s', $hsize);
  my $pad = 54 - length($name);
  $pad = 1 if $pad <= 0;
  $entry .= qq(<a\nhref="$href">$name</a>) . (' ' x $pad);
- $mtime = strftime('%Y-%m-%d %k:%M', gmtime($mtime));
+ $mtime = strftime('%Y-%m-%d %H:%M', gmtime($mtime));
  $entry .= $mtime . $hsize;
  }

diff --git a/xt/msgtime_cmp.t b/xt/msgtime_cmp.t
index 95d7c64b..6f4ca198 100644
--- a/xt/msgtime_cmp.t
+++ b/xt/msgtime_cmp.t
@@ -36,7 +36,7 @@ sub quiet_is_deeply ($$$$$) {
  ($old->[0] != $cur->[0]) ||
  ($old->[1] != $cur->[1]))) {
  for ($cur, $old) {
- $_->[2] = strftime('%Y-%m-%d %k:%M:%S', gmtime($_->[0]))
+ $_->[2] = strftime('%Y-%m-%d %H:%M:%S', gmtime($_->[0]))
  }
  is_deeply($cur, $old, "$func $oid");
  diag('got: ', explain($cur));


Regards,
Varun

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-05 20:22 [Patch] Update 24-hour times to use two digits for the hour Varun Varada
@ 2020-06-05 22:03 ` Eric Wong
  2020-06-05 22:48   ` Varun Varada
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Wong @ 2020-06-05 22:03 UTC (permalink / raw)
  To: Varun Varada; +Cc: meta

Varun Varada <varuncvarada@gmail.com> wrote:
> Hello,
> 
> Here is a patch to update the timestamps displayed to have 2 digits
> for the hour when since it is using the 24-hour clock:

Hello Varun, thanks for your interest in the project.

But why this patch?

It's a requirement to document the "why?" for submitting any
patch to any project.

>  # human-friendly format
> -sub fmt_ts ($) { strftime('%Y-%m-%d %k:%M', gmtime($_[0])) }
> +sub fmt_ts ($) { strftime('%Y-%m-%d %H:%M', gmtime($_[0])) }

As a human with degraded eyesight, I see leading zeros from
%H as visual noise which makes numbers harder to read.

%k uses a leading space instead of zero, but still uses two
digits for >=10 hours.  Pretty much any digital clock or timer
in the real world behaves the same way.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-05 22:03 ` Eric Wong
@ 2020-06-05 22:48   ` Varun Varada
  2020-06-05 23:27     ` Eric Wong
  2020-06-06 21:27     ` Dmitry Alexandrov
  0 siblings, 2 replies; 7+ messages in thread
From: Varun Varada @ 2020-06-05 22:48 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta

Hi Eric,

The "why?" is that leading zeroes are standard for virtually any
24-hour clock in the world
(https://www.google.com/search?q=24-hour+time). This is even codified
in the ISO 8601 standard
(https://en.wikipedia.org/wiki/ISO_8601#Times), which the project
seems to be following. Without a leading zero, a user immediately
expects an a.m./p.m. modifier, which there is not.

Varun

Varun


On Fri, 5 Jun 2020 at 17:03, Eric Wong <e@yhbt.net> wrote:
>
> Varun Varada <varuncvarada@gmail.com> wrote:
> > Hello,
> >
> > Here is a patch to update the timestamps displayed to have 2 digits
> > for the hour when since it is using the 24-hour clock:
>
> Hello Varun, thanks for your interest in the project.
>
> But why this patch?
>
> It's a requirement to document the "why?" for submitting any
> patch to any project.
>
> >  # human-friendly format
> > -sub fmt_ts ($) { strftime('%Y-%m-%d %k:%M', gmtime($_[0])) }
> > +sub fmt_ts ($) { strftime('%Y-%m-%d %H:%M', gmtime($_[0])) }
>
> As a human with degraded eyesight, I see leading zeros from
> %H as visual noise which makes numbers harder to read.
>
> %k uses a leading space instead of zero, but still uses two
> digits for >=10 hours.  Pretty much any digital clock or timer
> in the real world behaves the same way.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-05 22:48   ` Varun Varada
@ 2020-06-05 23:27     ` Eric Wong
  2020-06-06  0:11       ` Varun Varada
  2020-06-06 21:27     ` Dmitry Alexandrov
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Wong @ 2020-06-05 23:27 UTC (permalink / raw)
  To: Varun Varada; +Cc: meta

Varun Varada <varuncvarada@gmail.com> wrote:
> Hi Eric,
> 
> The "why?" is that leading zeroes are standard for virtually any
> 24-hour clock in the world
> (https://www.google.com/search?q=24-hour+time). This is even codified
> in the ISO 8601 standard
> (https://en.wikipedia.org/wiki/ISO_8601#Times), which the project
> seems to be following. Without a leading zero, a user immediately
> expects an a.m./p.m. modifier, which there is not.

Sorry, but no.  This project does NOT blindly follow ISO-8601 or
such standards when it comes to output intended for humans.

I admit the lack of AM/PM could be confusing at first in
standalone cases; but someone needs to learn that exactly once.

What I care more about is repeated tasks.  Making users focus
their eyes and waste energy parsing date and times for every
single thread they look at is much worse than training them
for one thing.

Take for example:
https://public-inbox.org/git/20200222201749.937983-1-sandals@crustytoothpaste.net/T/#t

2020-02-24 18:26   ` Junio C Hamano
2020-02-25 10:29   ` Johannes Schindelin
2020-02-25 19:25     ` Junio C Hamano
2020-02-26  3:05       ` brian m. carlson
2020-02-26  3:11         ` Junio C Hamano
2020-02-26  2:23     ` brian m. carlson
2020-02-27 13:24       ` Johannes Schindelin
2020-02-27 15:06         ` Junio C Hamano

With the leading space instead of zero, my eyes don't even need
to be in focus to know the replies from 2-26 were on a different
day than the rest.  The shape of the text is enough to tell,
I don't have to bring my eyes into focus to know that.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-05 23:27     ` Eric Wong
@ 2020-06-06  0:11       ` Varun Varada
  2020-06-06  0:27         ` Eric Wong
  0 siblings, 1 reply; 7+ messages in thread
From: Varun Varada @ 2020-06-06  0:11 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta

Hi Eric,

The issue of being able to determine whether a reply was on a
different day still arises with your method, as replies that occurred
before 12:00 on the same day would have the same problem. Either way,
it is just as easy to see the changeover to the next day if it was a
leading zero, as that indicates a reset of the clock, and it seems
like quite a subjective preference.

Nevertheless, it seems like the trade-off of making users learn
something once vs. repetitively is a false one, given that most people
are already familiar with seeing times with leading zeroes as 24-hour
times, and furthermore reading ISO 8601 formats in general. The idea
of "teaching one thing" in order to make the "output intended for
humans" ultimately easier to read seems to defeat its original
purpose, since people would have to unlearn what they already learned
every time they quickly glance through the output. I hope you'll
reconsider.

Regards,
Varun

On Fri, 5 Jun 2020 at 18:27, Eric Wong <e@yhbt.net> wrote:
>
> Varun Varada <varuncvarada@gmail.com> wrote:
> > Hi Eric,
> >
> > The "why?" is that leading zeroes are standard for virtually any
> > 24-hour clock in the world
> > (https://www.google.com/search?q=24-hour+time). This is even codified
> > in the ISO 8601 standard
> > (https://en.wikipedia.org/wiki/ISO_8601#Times), which the project
> > seems to be following. Without a leading zero, a user immediately
> > expects an a.m./p.m. modifier, which there is not.
>
> Sorry, but no.  This project does NOT blindly follow ISO-8601 or
> such standards when it comes to output intended for humans.
>
> I admit the lack of AM/PM could be confusing at first in
> standalone cases; but someone needs to learn that exactly once.
>
> What I care more about is repeated tasks.  Making users focus
> their eyes and waste energy parsing date and times for every
> single thread they look at is much worse than training them
> for one thing.
>
> Take for example:
> https://public-inbox.org/git/20200222201749.937983-1-sandals@crustytoothpaste.net/T/#t
>
> 2020-02-24 18:26   ` Junio C Hamano
> 2020-02-25 10:29   ` Johannes Schindelin
> 2020-02-25 19:25     ` Junio C Hamano
> 2020-02-26  3:05       ` brian m. carlson
> 2020-02-26  3:11         ` Junio C Hamano
> 2020-02-26  2:23     ` brian m. carlson
> 2020-02-27 13:24       ` Johannes Schindelin
> 2020-02-27 15:06         ` Junio C Hamano
>
> With the leading space instead of zero, my eyes don't even need
> to be in focus to know the replies from 2-26 were on a different
> day than the rest.  The shape of the text is enough to tell,
> I don't have to bring my eyes into focus to know that.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-06  0:11       ` Varun Varada
@ 2020-06-06  0:27         ` Eric Wong
  0 siblings, 0 replies; 7+ messages in thread
From: Eric Wong @ 2020-06-06  0:27 UTC (permalink / raw)
  To: Varun Varada; +Cc: meta

Varun Varada <varuncvarada@gmail.com> wrote:
> Hi Eric,
> 
> The issue of being able to determine whether a reply was on a
> different day still arises with your method, as replies that occurred
> before 12:00 on the same day would have the same problem.

True, there's cases where reading the date column is necessary;
but being able to optimize some cases is better than optimizing
none.

> Either way,
> it is just as easy to see the changeover to the next day if it was a
> leading zero, as that indicates a reset of the clock, and it seems
> like quite a subjective preference.

Maybe it's subjective, but having to parse whether a character
is '0' is more effort for me than recognizing a space.  My eyes
don't have to be in focus to recognize a space.

> Nevertheless, it seems like the trade-off of making users learn
> something once vs. repetitively is a false one, given that most people
> are already familiar with seeing times with leading zeroes as 24-hour
> times, and furthermore reading ISO 8601 formats in general. The idea
> of "teaching one thing" in order to make the "output intended for
> humans" ultimately easier to read seems to defeat its original
> purpose, since people would have to unlearn what they already learned
> every time they quickly glance through the output. I hope you'll
> reconsider.

Sorry, no, users need to learn UIs once.

Btw, please stop top-posting.  IMHO, not quoting public emails
at all is acceptable if you don't feel like deciding which parts
to quote.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Patch] Update 24-hour times to use two digits for the hour
  2020-06-05 22:48   ` Varun Varada
  2020-06-05 23:27     ` Eric Wong
@ 2020-06-06 21:27     ` Dmitry Alexandrov
  1 sibling, 0 replies; 7+ messages in thread
From: Dmitry Alexandrov @ 2020-06-06 21:27 UTC (permalink / raw)
  To: Varun Varada; +Cc: Eric Wong, meta


[-- Attachment #1.1: Type: text/plain, Size: 292 bytes --]

Varun Varada <varuncvarada@gmail.com> wrote:
> The "why?" is that leading zeroes are standard for virtually any 24-hour clock in the world

> any

Nope, at least not for my Electronica-52 watches.  I am too lazy to look for them to take a photo, but thankfully itʼs easily googleable:

[-- Attachment #1.2: electronica-52.jpg --]
[-- Type: image/jpeg, Size: 61368 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 382 bytes --]


> virtually any

I strongly suspect, the same is true for all models of Electronica watches.  I also suspect, that Montana, whose appearance Bielorussian designers were undoubtedly inspired by, does not feature any leading zeroes either.

> Without a leading zero, a user immediately expects an a.m./p.m. modifier

As youʼve already guessed, at least I absolutely donʼt.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-05 20:22 [Patch] Update 24-hour times to use two digits for the hour Varun Varada
2020-06-05 22:03 ` Eric Wong
2020-06-05 22:48   ` Varun Varada
2020-06-05 23:27     ` Eric Wong
2020-06-06  0:11       ` Varun Varada
2020-06-06  0:27         ` Eric Wong
2020-06-06 21:27     ` Dmitry Alexandrov

user/dev discussion of public-inbox itself

Archives are clonable:
	git clone --mirror https://public-inbox.org/meta
	git clone --mirror http://czquwvybam4bgbro.onion/meta
	git clone --mirror http://hjrcffqmbrq6wope.onion/meta
	git clone --mirror http://ou63pmih66umazou.onion/meta

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta
	nntp://ou63pmih66umazou.onion/inbox.comp.mail.public-inbox.meta
	nntp://czquwvybam4bgbro.onion/inbox.comp.mail.public-inbox.meta
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.mail.public-inbox.meta
	nntp://news.gmane.io/gmane.mail.public-inbox.general

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git