Add years and months to the human date formatter

[ValentinLeTallec]

Hi, the current implementation of the human formatter uses days as its biggest unit, I added years and months

Before :

>>> 2 yr + 50 days -> human
  human(2 year + 50 day)
    = 780 days + 11 hours + 37 minutes + 30.103680 seconds    [String]

>>> 2 yr + 50 s -> human
  human(2 year + 50 second)
    = 730 days + 11 hours + 38 minutes + 20.103680007 seconds    [String]

After :

>>> 2 yr + 50 days -> human
  human(2 year + 50 day)
    = 2 years + 1 month + 19 days + 13 hours + 30 minutes + 56.246 seconds    [String]

>>> 2 yr + 50 s -> human
  human(2 year + 50 second)
    = 2 years + 50 seconds    [String]

P.S Love numbat ^^

[ValentinLeTallec]

I'm not quite sure what the error in the CICD is about 🤔
I think I will need some insight from you before I am able to fix it.

thread 'modules_are_self_consistent' panicked at 'assertion failed: result.is_ok()', numbat/tests/prelude_and_examples.rs:24:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    modules_are_self_consistent

test result: FAILED. 5 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.00s

error: test failed, to rerun pass `-p numbat --test prelude_and_examples`
Error: Process completed with exit code 101.

[triallax]

Thanks for your contribution!

Days, minutes, hours, and seconds have a more or less constant value, unlike months and years which can have different lengths (notwithstanding that we have them in Numbat as average values), so I think we might want to think twice about adding them to human due to the lack of precision. But to be honest, given that we already have year and month as average values, the cat may be out of the bag for this already.

[sharkdp]

Also, please note that we have an open PR targeting human here: #400

[sharkdp]

I'm not quite sure what the error in the CICD is about 🤔

This test makes sure that all modules can be used in a standalone way. You can reproduce the error in the following way: start numbat with the --no-prelude option. Then, try to import the module (in this case: use datetime::human). You will probably get an error like "sidereal_day not defined". This can be fixed by including the necessary modules in numbat/modules/datetime/human.nbt.

[ValentinLeTallec]

Days, minutes, hours, and seconds have a more or less constant value, unlike months and years which can have different lengths (notwithstanding that we have them in Numbat as average values), so I think we might want to think twice about adding them to human due to the lack of precision. But to be honest, given that we already have year and month as average values, the cat may be out of the bag for this already.

Yeah, I do think it makes sense considering those units already exist in numbat (and the documentation does have proper warnings about them being average value).

To me -> human feels more about having an easy-to-read duration than a precise one. When more precision is needed, I would naturally gravitate toward conversions to a specific unit.

As a side note on the subject, I was wondering if, for durations greater than a month, it would be more ergonomic to hide the hours, minutes and seconds, as 1 year + 11 months + 6 days + 22 hours + 51 minutes + 33.65 seconds ago get somewhat long (maybe 1 year + 11 months + 6.95 days ? or just 1 year + 11 months + 7 days by rounding)

Also, please note that we have an open PR targeting human here: #400

I added the management of the negative time to this pull request (I have used ago because that what is used in #400)

This test makes sure that all modules can be used in a standalone way. You can reproduce the error in the following way: start numbat with the --no-prelude option. Then, try to import the module (in this case: use datetime::human). You will probably get an error like "sidereal_day not defined". This can be fixed by including the necessary modules in numbat/modules/datetime/human.nbt.

Yep, thanks, I solved it ^^

[sharkdp]

I'm not completely sure about this. As @triallax mentioned, human is a precise transformation for now. Once we add months and years, the interpretation is not completely clear.

I'm with you (@ValentinLeTallec) that we're often just interested in a rough estimation. But in this case, I can already call 10000 days -> months or 1e9 days -> years. I don't need human for that. I do need it if I am interested in splitting a decimal timespan into hours/minutes/seconds (7000 seconds -> human). Here, I actually do care how many minutes and seconds I get, not just how many hours. Otherwise, I could have called (7000 seconds -> hours).

We may want to have that same feature (split a time span into mixed units) for years/months/days as well, but then the imprecision bothers me.

[ValentinLeTallec]

Yeah, it does make sens to keep precise measurements for the use case you are describing.

I think the current version is more geared toward a human_time and what I had in mind is more of an human_date.

My use case would be more something like :

>>> date("2025-12-12") - today() -> human
  human(date("2025-12-12") - today())
    = 1 year + 6 months + 27 days    [String]

Maybe we could separate it in two functionalities ?

[sharkdp]

My use case would be more something like :

>>> date("2025-12-12") - today() -> human
  human(date("2025-12-12") - today())
    = 1 year + 6 months + 27 days    [String]

But in this exact use case, the imprecision actually bothers me. I don't want this to be off by 1 day.

[ValentinLeTallec]

Then maybe more like that :

>>> date("2025-12-12") - today() -> human_date
  human(date("2025-12-12") - today())
    = 1 year + 6 months + 16.18 days    [String]

?