fix: Improve recurring invoicing due date calculation logic - #34
Conversation
WalkthroughThe change modifies the calculation logic for the new due date in the webhook route’s POST function. Instead of adding the original interval between the issued and due dates to the current date, the new approach sets the current date and the original dates to midnight UTC, computes the difference in days between the issued and due dates, and then adds this difference to the current date. This adjustment ensures that all date calculations are performed in UTC. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant WebhookHandler
participant DateUtils
Client->>WebhookHandler: Send POST request for recurring request
WebhookHandler->>DateUtils: Get current date (set to midnight UTC)
DateUtils-->>WebhookHandler: Return current UTC date
WebhookHandler->>DateUtils: Normalize issued and due dates to midnight UTC
DateUtils-->>WebhookHandler: Return normalized dates
WebhookHandler->>WebhookHandler: Calculate days difference between dates
WebhookHandler->>DateUtils: Add days difference to current date
DateUtils-->>WebhookHandler: Return new due date
WebhookHandler->>Client: Respond with updated due date
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/app/api/webhook/route.ts (1)
69-93: Consider using a date utility libraryWhile the current implementation is correct, consider using a date utility library like date-fns or Luxon for more readable and maintainable date operations. These libraries provide dedicated functions for day-difference calculations and date manipulations that could simplify this code.
- // Calculate the difference in days between original issue and due dates - const originalIssuedDate = new Date(issuedDate); - originalIssuedDate.setUTCHours(0, 0, 0, 0); // Set to midnight UTC due to rounding - - const originalDueDate = new Date(dueDate); - originalDueDate.setUTCHours(0, 0, 0, 0); // Set to midnight UTC due to rounding - - // Calculate days difference using UTC dates to avoid timezone issues - const daysDifference = Math.max( - 0, - Math.floor( - (originalDueDate.getTime() - originalIssuedDate.getTime()) / - (24 * 60 * 60 * 1000), - ), - ); - - // Calculate new due date by adding the same number of days to the new issue date - const newDueDate = new Date(now); - newDueDate.setDate(now.getDate() + daysDifference); + // Calculate the difference in days between original issue and due dates using date-fns + import { differenceInDays, addDays, startOfDay, parseISO } from 'date-fns'; + + const originalIssuedDate = startOfDay(parseISO(issuedDate)); + const originalDueDate = startOfDay(parseISO(dueDate)); + + // Calculate days difference (ensure it's not negative) + const daysDifference = Math.max(0, differenceInDays(originalDueDate, originalIssuedDate)); + + // Calculate new due date by adding the same number of days + const newDueDate = addDays(now, daysDifference);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/app/api/webhook/route.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Build
🔇 Additional comments (4)
src/app/api/webhook/route.ts (4)
71-72: Good use of UTC standardization for date handlingSetting the current date to midnight UTC is a solid approach to eliminate timezone-related inconsistencies in the due date calculations. This ensures that regardless of where the server is located, the date calculation starts from a consistent reference point.
75-79: Proper normalization of reference datesSetting both the original issued and due dates to midnight UTC is crucial for accurate day-difference calculation. This approach effectively eliminates any time-of-day variations that could cause rounding errors in the calculation.
82-88: Robust day-difference calculationThe implementation correctly:
- Uses UTC timestamps to avoid timezone issues
- Applies Math.floor to ensure whole day counting
- Uses Math.max to prevent negative durations
This approach effectively addresses the rounding issues mentioned in the PR objectives.
91-92: Clean implementation of new due date calculationUsing the day difference to calculate the new due date ensures consistent intervals between issued and due dates across recurring invoices. This maintains the original payment terms while fixing the date calculation issues.
Problem
Due date calculation was facing rounding issues so creating wrong due dates for the recurring invoices.
Changes
Use UTC dates to avoid rounding and timezones issues
Summary by CodeRabbit