Improve null handling in getNextQuotaReset

[pavankumar-vh]

Overview

Improve null handling in the getNextQuotaReset function in common/src/util/dates.ts.

Bug Description

The original code used referenceDate ?? now which meant when referenceDate was null, it created a new Date from now, then the while loop would immediately add a month since nextMonth <= now would be true (they're equal).

This is inefficient and the intent is unclear.

Fix

Made the null case explicit:

• When referenceDate is null, return next month from now directly
• When referenceDate is provided, start from that date and add months until it's in the future

Testing

No existing tests for this function, but the fix improves clarity and efficiency.

Files Changed

• common/src/util/dates.ts - Improved null handling

Scope

This change only touches common/ which is an approved contribution area per the Contributing Guide.

[codebuff-team]

Thanks for taking a look at dates.ts, but I don't think this changes anything. Walk through the original logic: when referenceDate is null, nextMonth = new Date(now), then the while loop runs exactly once (since nextMonth <= now is true when they're equal) and adds one month. That is exactly the same result your new early-return branch produces — next.setMonth(next.getMonth() + 1) off of now.

There's no inefficiency being fixed: the loop only executes a single iteration in the null case, not an unbounded number. It's not doing extra work, and the output is identical for every input. The PR description asserts a bug ("the while loop would immediately add a month") but that's the intended and correct behavior, not a defect — quota reset should always be strictly in the future relative to now.

Splitting into two code paths does add a few lines without adding test coverage, and since the behavior is unchanged there's nothing to validate against anyway. If you want to improve this function, a better target would be adding tests for getNextQuotaReset covering both the null and non-null cases, or handling the edge case where referenceDate is far in the past/future across DST or month-length boundaries (e.g. Jan 31 -> Feb 28/29 rollover), which the current setMonth loop can behave oddly with.

Closing as this doesn't change observable behavior and the stated bug doesn't exist.