Codecov Report

❌ Patch coverage is 87.50000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.92%. Comparing base (aa5d5fb) to head (f9ad772).
⚠️ Report is 3 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #2150      +/-   ##
===========================================
+ Coverage    41.58%   41.92%   +0.34%     
===========================================
  Files          394      394              
  Lines        12495    12521      +26     
  Branches      2979     2981       +2     
===========================================
+ Hits          5196     5250      +54     
+ Misses        4973     4945      -28     
  Partials      2326     2326              

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

I made the Ops -> Operations change, added some comments above some of the sections that Denis mentioned in his review feedback, and made a couple of simplifications/refactors.

Regarding the time computations themselves, yes, it'd be great to make the arithmetic time manipulations more readable and type-safe. For example, to change stuff like:

const lastDay: middle + 3 * TimeConstants.DAY_MILLIS;

to

const lastDay: middle.add(3, 'days');

However, I have not found an existing library that looks robust and well-designed enough to be used confidently. We need to implement the time series adjustments precisely in UTC, without accidentally lapsing to local time or DST, otherwise time series that have been generated at different times may become misaligned with each other or mislabeled when displayed in our UI (which is bad). Such problems can also potentially be huge PITA to debug and remedy, if they only happen occasionally and are buried deep in the library somewhere.

Lots of the existing libraries have mutable date representations, which are an open invitation to future bugs and should be avoided. dayjs looks ok, but I'm not confident in its overall robustness, especially since the utc and duration functionality are bolted on via plugins. Due to its design, it would also be easy to misuse dayjs in ways that seemed superficially correct, or wherein the incorrectness was easy to miss.

So, I strongly recommend staying with the existing arithmetic time computations for now. To help, I've added commented and simplified the ones that might be confusing.

After the new Temporal API https://tc39.es/proposal-temporal/ is finalized and released, we should consider using it (easy to do). It's very similar to the time APIs introduced in Java 8, which are very well designed, and we use to implement similar functionality in the webservice. Also, built-in libraries are also likely to be very-stringently vetted, better documented, and more functionality correct. Using the Temporal API's Instant throughout would be the ticket.

However, I have not found an existing library that looks robust and well-designed enough to be used confidently.

Try taking a look at https://github.com/you-dont-need/You-Dont-Need-Momentjs/blob/master/README.md#brief-comparison and the code examples, I'm not wedded to any of the three. But I do think that a lot of time has been spent by others looking at and working on them and they deserve more time/consideration.

In particular

Lots of the existing libraries have mutable date representations

• day.js isn't mutable by default. In fact, you need to turn on a non-recommended plugin to get that https://day.js.org/docs/en/plugin/bad-mutable
• luxon is immutable https://moment.github.io/luxon/#/moment?id=immutability
• date-fns claims immutability right in the readme https://github.com/date-fns/date-fns

bolted on via plugin

I think this is intentional to reduce library size and not meant as a comment on quality.
Note the extremely small size of the library in the table comparison.

Also, built-in libraries are also likely to be very-stringently vetted, better documented, and more functionality correct.

I don't necessarily disagree with this, and it may be worth a deeper look since it may have released this year? ( https://computus.org/when-can-i-use-temporal/ ) . The larger point is that if we further pursue the line of thought as to which alternative is better vetted and documented, that doesn't really act as an argument for our own date/time code which we know for sure has few eyes on it.

Another interesting compromise/possibility https://www.npmjs.com/package/temporal-polyfill

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

I changed the "interval operations" code to use @js-temporal/polyfill. Overall, readability/understandability is a wash. There are some lamenesses in the Javascript Temporal API design (like not supporting the addition/subtraction of fractional amounts of duration units) that make the code less understandable than it would be otherwise. Type safety is improved. Given that the previous implementation was simple enough that we could have proved its correctness mathematically, reliability goes down. I am super-skeptical of date-time libraries in general, they are very difficult to implement and they don't always fail immediately (why hello there February 29). Hope this one doesn't cause any problems in the future. Would have been helpful to merge the non-Temporal version as a placeholder implementation, this PR includes some modifications that match the recent webservice TimeSeriesMetric changes that were necessary to get the UI to build. Without those merged, in some other upcoming UI PRs, I had to burn time/energy realizing, reimplementing, and mentally tracking them.