Improve natural unit conversion for a time b/w 360 to 365 days #3901
Conversation
Previously, 363 days would be converted to 12.1 months, which is quite confusing because - a user would think that if the value is more than 12 months, why it isn't displayed in years - the value is actually less than a year, which is counterintuitive as 12.1 m suggests a value more than a year.
ts/lib/tslib/time.ts
Outdated
| } else if (secs < MONTH) { | ||
| return TimespanUnit.Days; | ||
| } else if (secs < YEAR) { | ||
| } else if (secs < 12.0 * MONTH) { |
There was a problem hiding this comment.
Why is it necessary to keep the old behaviour (i.e a year being 360 days) here?
There was a problem hiding this comment.
If we make it 365 days here, a time like 363 days would be displayed as 12.1 months, which is confusing.
I am adding another test in the corresponding Rust code that would fail if the part corresponding to this is changed in the Rust code.
|
While I appreciate the problem you're trying to solve, I find this approach a bit confusing as we're special-casing one unit. What if we just made the month constant more accurate? It's likely going to require some tests to be updated too though. diff --git a/rslib/src/scheduler/timespan.rs b/rslib/src/scheduler/timespan.rs
index f98c1ce69..bdbbdaeab 100644
--- a/rslib/src/scheduler/timespan.rs
+++ b/rslib/src/scheduler/timespan.rs
@@ -57,7 +57,7 @@ const SECOND: f32 = 1.0;
const MINUTE: f32 = 60.0 * SECOND;
const HOUR: f32 = 60.0 * MINUTE;
const DAY: f32 = 24.0 * HOUR;
-const MONTH: f32 = 30.0 * DAY;
+const MONTH: f32 = 30.417 * DAY;
const YEAR: f32 = 365.0 * DAY;
#[derive(Clone, Copy)]
@@ -189,5 +189,9 @@ mod test {
assert_eq!(time_span(90.0, &tr, false), "1.5 minutes");
assert_eq!(time_span(45.0 * 86_400.0, &tr, false), "1.5 months");
assert_eq!(time_span(365.0 * 86_400.0 * 1.5, &tr, false), "1.5 years");
+ assert_eq!(time_span(364.0 * 86_400.0, &tr, false), "12 months");
+ assert_eq!(time_span(364.0 * 86_400.0, &tr, true), "11.97 months");
+ assert_eq!(time_span(365.0 * 86_400.0, &tr, false), "1 year");
+ assert_eq!(time_span(365.0 * 86_400.0, &tr, true), "1 year");
}
} |
|
I updated the PR to use the average duration of month (as you suggested) and updated the relevant tests. |
|
Thank you! |
|
@user1823 The Will this change mean that power users will 'lose' progress if their 'total studied' time is > 1 month? anki/ts/routes/graphs/reviews.ts Line 118 in 615bbf9
|
|
@david-allison, I suppose that you mean the reviews section of the statistics, not settings. Yes, you are right. Unfortunately, this change has the side effect of slightly decreasing the reported total study time if that's more than a month. Also, as you said, I too feel that using "months" to describe study time is weird. This has been discussed on the forums too and Damien would accept a PR that prevents the study time from being shown in a unit greater than "hours". https://forums.ankiweb.net/t/reviews-graph-units-of-total-time-studied-suggestion/61237/14 Edit: I opened a PR |
* Add maxUnit argument to naturalUnit * Limit study time to hours in reviews graph Relevant discussions: - https://forums.ankiweb.net/t/reviews-graph-units-of-total-time-studied-suggestion/61237 - https://forums.ankiweb.net/t/why-does-anki-display-study-time-in-months/37722 - https://forums.ankiweb.net/t/poll-use-hours-in-total-time-stats/62076 - #3901 (comment) * Use the new approach for native stability in Card Info * Use a simpler approach
Previously, 363 days would be converted to 12.1 months, which is quite confusing because