Why define a new function, instead of adding optional arguments to the existing one?

No real reason; new patch doing so attached.

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

The last column is obviously the most compact while still conveying a good amount of information, but the 1yr mastodon and normal READABLE s-to-s are also quite good (effectively equivalent to magit--age) for a quick glance and maintaining ~constant widths. I do find it awkward to set the RESOLUTION argument to >30 million seconds to achieve this. It took me a bit to understand what this argument does.

Code use to produce:

(concat

(format "%11s %10s %18s %18s %12s %12s %s\n" "Delay (s)" "s-to-s"

"mastodon" "mastodon (3600s)" "mast (1yr)" "s-to-s (rdb)" "s-to-s (rdb=abbrev, half)")

(cl-loop for s = 0.45 then (* s 2.3) while (< s (* 365.25 24 3600 22))

concat (format "%11.1f %10s %18s %18s %12s %12s %s\n" s

(seconds-to-string s)

(car (mastodon-tl--human-duration s))

(car (mastodon-tl--human-duration s 3600))

(car (mastodon-tl--human-duration s (* 365.25 24 3600)))

(seconds-to-string s t)

(seconds-to-string s 'abbrev 'half))))