fix(time-duration): Time Duration Most Significant adjusted to not have approax value

[rahul-p-rajesh]

Description

Problem: On Providing an input like 44H, the output is 1 day.
Fix: Added an allowApproxUnit flag which on false keeps on checking the for time unit which is not approximate.

Checklist:

• ✅ My changes generate no new warnings
• ✅ I have added tests that prove my fix is effective or that my feature works
• ✅ Any dependent changes have been merged and published in downstream modules

[github-actions]

Test Results

    4 files  ±0    316 suites  ±0   32m 36s ⏱️ +3s
1 136 tests ±0  1 136 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 146 runs  ±0  1 146 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit f15d131. ± Comparison against base commit 389047b.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (389047b) 81.69% compared to head (f15d131) 81.70%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2589   +/-   ##
=======================================
  Coverage   81.69%   81.70%           
=======================================
  Files         928      928           
  Lines       20790    20793    +3     
  Branches     3136     3139    +3     
=======================================
+ Hits        16984    16988    +4     
+ Misses       3665     3664    -1     
  Partials      141      141           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aaron-steinfeld]

Problem: On Providing an input like 44H, the output is 1 day.
Fix: Added an allowApproxUnit flag which on false keeps on checking the for time unit which is not approximate

That's the whole point of the function though. In that example, 'day' is the most significant unit. The behavior you're describing is something else, so we shouldn't overload the existing function with a boolean flag (code smell!). We'd want a whole new function. That said, given we already can represent this as a 1d20h and as 1d, do we really need a third representation? The UX consistency here is concerning.