Create option to humanize time output

[mmarras]

This touches on #1459.

I am (again) trying to get a human friendly version of a time. Somewhat with the same intention why https://pypi.org/project/humanize/ exists.

Background is that I want to show time data in a human friendly way. ks, Ms etc are not helpful here.

102123123 s, very few humans will be able to comprehend. I can do ureg.Quantity('102123123 s').to_compact() and get 102.12... Ms. So how long is that again? Only when I do ureg.Quantity('102123123 s').to('a') and get 3.23…. a, I can appreaciate what that time means. However, I will have to know a-priory what the meaningful time-unit is to convert into for this particular case. But if I got 0.323 years as result it would not be a nice result either. It's just not how we are used to think about time. When dealing with large fractions of a year I expect the results in months (0.323 years are 3.87 month).

I am proposing to create a modification of to_compact which will automatically convert units of dimension [time] to a suitable humanfriendly time unit. Suitable time unit in my opinion (but that's possibly up for debate) is the time unit which leaves the magnitude with at least one, but the least amount of integer parts. So the time unit should be the "biggest" which doesn't leave the magnitude to be purely fractional so no 0.XXX years (because then I want months!), but 1.212 years is fine.

Example:

1001 ms should convert to 1.001 s
59 s should still be 59 s
but 60 s should be 1.0 min
61 min should be 1.01... h
and so on.
I'm not sure if pint implements a decade but it does implement a century
so finally
ureg.Quantity('10231231232s ').to_compact(humantime=True) -> 3.23 century
(again millenium seem not to be implemented, eon is, maybe that's another topic to pick up: https://en.wikipedia.org/wiki/Unit_of_time, but not to dilute this post).

As demonstrated above, to_compact(), to_preferred() and to_base_units() are related but don't get the job done out of the box.

[andrewgsavage]

Yes, that would be a nice feature to have. A PR is welcomed! I think the same logic could be used to determine whether to use ft or inch etc. Possibly also the comparisons Wolfram Alpha gives, eg 5 ton is Comparisons [image: ≈ 0.8 × mass of a typical large elephant ( ≈ 6000 kg )] ------------------------------ [image: ≈ 2.7 × mass of a typical small car ( ≈ 1700 kg )] ------------------------------ [image: ≈ 6 × mass of a typical dairy cow ( ≈ 700 kg )] One thing to be careful of is a user may use their own units instead of those defined in default_en.txt, so ideally there would be a way to specify which time units are to be used in humantime

…

On Tue, Nov 26, 2024 at 12:17 PM Matthias Arras ***@***.***> wrote: This touches on #1459 <#1459>. I am (again) trying to get a human friendly version of a time. Somewhat with the same intention why https://pypi.org/project/humanize/ exists. Background is I want to show time data in a human friendly way. k, M etc are not helpful here. 102123123 s, very few humans will be able to comprehend. I can do ureg.Quantity('102123123 s').to('a') and get 3.23... a. Nice but I will have to know apriory what the meaningful time-unit is here. I am proposing to create a modification to_compact which will automatically convert units of dimension [time] to a suitable humanfriendly time unit. Suitable time unit is the time unit which leaves the magnitude with at least one but the least amount of integer parts. Example: 1001 ms should convert to 1.001 s 59 s should still be 59 s but 60 s should be 1.0 min 61 min should be 1.01... h and so on. I'm not sure if pint implements a decade but it does implement a century so finally ureg.Quantity('10231231232s ').to_compact(humantime=True) -> 3.23 century (again millenium seem not to be implemented, eon is, maybe that's another topic to pick up: https://en.wikipedia.org/wiki/Unit_of_time, but not to dilute this post). As demonstrated above, to_compact(), nor to_preferred() nor to_base_units() are helpful but don't get the job done out of the box. — Reply to this email directly, view it on GitHub <#2080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEMLECJXZC4XFMVFQJAAJ32CRRDXAVCNFSM6AAAAABSQJMVKOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4TINBXGA3TQMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mmarras]

So I guess one way to go about is to get all units of dimension [time] in the registry. Then rank them by “size” and then start at the lowest one until we get the first non-zero integer part.
would that be flexible enough?

[andrewgsavage]

Yes. I think that could pick up too many units, but it's a good starting point. It would be good to be able to set the list of units to rank after registry init too.

…

On Tue, 26 Nov 2024, 13:49 Matthias Arras, ***@***.***> wrote: So I guess one way to go about is to get all units of dimension [time] in the registry. Then rank them by “size” and then start at the lowest one until we get the first non-zero integer part. would that be flexible enough? — Reply to this email directly, view it on GitHub <#2080 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEMLEE7VLBLBW2TC65QAJT2CR36TAVCNFSM6AAAAABSQJMVKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBQHA2TEOJXGM> . You are receiving this because you commented.Message ID: ***@***.***>