Varun Varada 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
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 t
Varun Varada 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
>
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 lea
Varun Varada 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
p
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 +1
