GNU bug report logs -
#71572
[PATCH] seconds-to-string-approximate
Previous Next
Reported by: JD Smith <jdtsmith <at> gmail.com>
Date: Sat, 15 Jun 2024 17:25:01 UTC
Severity: wishlist
Tags: patch
Merged with 71573
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #33 received at 71572 <at> debbugs.gnu.org (full text, mbox):
> From: JD Smith <jdtsmith <at> gmail.com>
> Date: Sat, 22 Jun 2024 22:16:40 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 71572 <at> debbugs.gnu.org,
> Adam Porter <adam <at> alphapapa.net>,
> jonas <at> 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.
This bug report was last modified 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.