From: Eli Zaretskii <eliz@gnu.org>
To: JD Smith <jdtsmith@gmail.com>
Cc: adam@alphapapa.net, 71572@debbugs.gnu.org, jonas@bernoul.li,
eggert@cs.ucla.edu
Subject: bug#71572: [PATCH] seconds-to-string-approximate
Date: Thu, 04 Jul 2024 08:29:03 +0300 [thread overview]
Message-ID: <86msmxafog.fsf@gnu.org> (raw)
In-Reply-To: <CE7E0586-64CF-42FA-9C9E-EB811623C68B@gmail.com> (message from JD Smith on Sat, 22 Jun 2024 22:16:40 -0400)
> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 22 Jun 2024 22:16:40 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>,
> 71572@debbugs.gnu.org,
> Adam Porter <adam@alphapapa.net>,
> jonas@bernoul.li
>
> > Why not look at what mastodon.el does, as the comment in seconds-to-string suggests? For example, mastodon-tl--human-duration lets you specify whatever resolution you want, instead of limiting you to either 0.5 or 1 as in the proposed patch.
>
> I see that mastodon is a package in ELPA, so doesn't satisfy the need in core. I took a look at this function. The RESOLUTION mentioned is not equivalent to the HALF argument, it is the minimum resolution in seconds. So setting it to e.g. 3600 results in truncating to the hour, but changes nothing below the hour. Setting it to the number of seconds in a year gives something quite similar to magit--age (though I notice the mastodon function truncates, instead of rounds; see, e.g., 2.98y in the table below).
>
> Here's a comparison among:
>
> - the current seconds-to-string
> - mastodon-tl--human-duration
> - mastodon with a 3600s resolution
> - mastodon with 1yr "resolution"
> - the new seconds-to-string with option READABLE=t
> - new seconds-to-string with abbreviated units and half unit resolution
>
> Delay (s) s-to-s mastodon mastodon (3600s) mast (1yr) s-to-s (rdb) s-to-s (rdb=abbrev, half)
> 0.5 450.00ms 0 sec 0 sec 0 sec 0 seconds ½s
> 1.0 1.03s 1 sec 1 sec 1 sec 1 second 1s
> 2.4 2.38s 2 secs 2 secs 2 secs 2 seconds 2½s
> 5.5 5.48s 5 secs 5 secs 5 secs 5 seconds 5½s
> 12.6 12.59s 12 secs 12 secs 12 secs 13 seconds 12½s
> 29.0 28.96s 28 secs 28 secs 28 secs 29 seconds 29s
> 66.6 66.62s 1 min 1 min 1 min 1 minute 1m
> 153.2 2.55m 2 mins 2 mins 2 mins 3 minutes 2½m
> 352.4 5.87m 5 mins 5 mins 5 mins 6 minutes 6m
> 810.5 13.51m 13 mins 13 mins 13 mins 14 minutes 13½m
> 1864.2 31.07m 31 mins 31 mins 31 mins 31 minutes 31m
> 4287.6 71.46m 1 hour, 11 mins 1 hour 1 hour 1 hour 1h
> 9861.6 2.74h 2 hours, 44 mins 2 hours 2 hours 3 hours 2½h
> 22681.6 6.30h 6 hours, 18 mins 6 hours 6 hours 6 hours 6½h
> 52167.8 14.49h 14 hours, 29 mins 14 hours 14 hours 14 hours 14½h
> 119985.9 1.39d 1 day, 9 hours 1 day, 9 hours 1 day 1 day 1½d
> 275967.5 3.19d 3 days, 4 hours 3 days, 4 hours 3 days 3 days 3d
> 634725.2 7.35d 1 week 1 week 1 week 1 week 1w
> 1459867.9 16.90d 2 weeks, 2 days 2 weeks, 2 days 2 weeks 2 weeks 2½w
> 3357696.2 38.86d 1 month, 1 week 1 month, 1 week 1 month 1 month 1½M
> 7722701.2 89.38d 2 months, 4 weeks 2 months, 4 weeks 2 months 3 months 3M
> 17762212.9 205.58d 6 months, 3 weeks 6 months, 3 weeks 6 months 7 months 7M
> 40853089.6 1.29y 1 year, 3 months 1 year, 3 months 1 year 1 year 1½Y
> 93962106.0 2.98y 2 years, 11 months 2 years, 11 months 2 years 3 years 3Y
> 216112843.8 6.85y 6 years, 10 months 6 years, 10 months 6 years 7 years 7Y
> 497059540.7 15.75y 15 years, 9 months 15 years, 9 months 15 years 16 years 16Y
Basically, this shows that:
. mastodon truncates where seconds-to-string rounds
. seconds-to-string lacks the "1 hour 11 min" output format
. seconds-to-string sometimes produces inaccurate results, as in
5.5 => 5.48s
The last item worries me: can we fix this, please?
The second item sounds like a useful feature, so maybe an optional
behavior could provide it as well?
Thanks.
next prev parent reply other threads:[~2024-07-04 5:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-15 17:24 bug#71573: [PATCH] seconds-to-string-approximate JD Smith
2024-06-15 17:36 ` Eli Zaretskii
2024-06-17 6:20 ` bug#71573: Related functions from ts.el Adam Porter
2024-06-22 10:55 ` Stefan Kangas
2024-06-22 21:54 ` Adam Porter
2024-06-22 8:45 ` bug#71572: [PATCH] seconds-to-string-approximate Eli Zaretskii
2024-06-22 21:56 ` Adam Porter
2024-06-22 23:42 ` Paul Eggert
2024-06-23 2:16 ` JD Smith
2024-07-04 5:29 ` Eli Zaretskii [this message]
2024-07-04 6:04 ` Eli Zaretskii
2024-07-04 7:09 ` Paul Eggert
2024-07-06 19:29 ` JD Smith
2024-07-06 21:09 ` Paul Eggert
2024-07-11 21:01 ` JD Smith
2024-07-04 15:27 ` JD Smith
2024-07-04 15:59 ` Eli Zaretskii
2024-07-04 17:16 ` JD Smith
2024-07-04 18:06 ` Eli Zaretskii
2024-07-04 16:36 ` Ihor Radchenko
2024-07-04 17:23 ` JD Smith
2024-07-04 17:57 ` Ihor Radchenko
2024-06-23 5:13 ` Eli Zaretskii
2024-07-03 20:32 ` JD Smith
2024-07-04 5:29 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86msmxafog.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71572@debbugs.gnu.org \
--cc=adam@alphapapa.net \
--cc=eggert@cs.ucla.edu \
--cc=jdtsmith@gmail.com \
--cc=jonas@bernoul.li \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).