Calculating Deadlines in Working Days for Application Processing Systems
Application processing systems require tracking working days instead of calendar days for accurate deadline calculations. The count begins on the day of publication during business hours, or on the next business day if published outside the schedule. The calendar is automatically loaded from an external service at startup and checked daily for data for the current and next year. Without a calendar, the system falls back to calendar days.
Registration occurs instantly upon publication, without waiting for a business day. For example: publication at 11:00 PM on a business day shifts the start to the next business day; publication at 6:00 AM on the same day remains the current day if the schedule starts later.
Rules for Displaying the Counter
The counter shows the number of full working days that have passed. Regardless of the publication time, on the start day of the deadline, it displays 0/N.
- Publication day during business hours: 0/N until 00:00 the next day.
- Publication outside the schedule: 0/N until 00:00 of the first business day.
The counter increments at 00:00 after a full business day has ended. A deadline is considered missed when the value is ≥ N (e.g., 5/5).
Alternatives Rejected in Discussion
- Counter starting at 1/N from the moment of publication — complicates the perception of full days.
- Incrementing at the end of the business day — ignores employee delays.
- Marking as overdue at the end of the business day — unintuitive for 5:59 PM vs. 6:01 PM.
Calculation Examples
Example 1: Publication on January 1 (a holiday), first business day January 12, deadline January 16 (5 days). Processing on January 13 — counter 1/5 (full day: only January 12).
Example 2: 2 days for processing, publication on a business day at 9:00 AM (Monday). Monday: 0/2; Tuesday: 1/2; midnight Tuesday: 2/2 (overdue).
Example 3: Same task, publication at 8:00 PM Monday. Monday: 0/2; Tuesday: 0/2; Wednesday: 1/2; midnight Wednesday: 2/2.
Time zones are unified to server time for simplicity.
Implementation Nuances in Backend
- Cache the calendar in memory: current year + next year (with cleanup of old data).
- Record counter values and original deadlines in the database for each application — minimizes recalculations.
- Store deadline history: a separate table for configurations by type/period or a column on the entity.
Calendar update: API requests at startup, daily at 00:00.
Testing Key Scenarios
Test behavior in real-time or simulate via database/API:
- Normal business day.
- Holiday.
- Evening of a business day (after schedule).
- Absence of calendar — fallback and auto-update.
- Overdue and normal deadlines.
- Load: multiple calendars across years.
- Dormant API services.
Key Points
- The count begins on the day of publication within the schedule or the next business day.
- Counter: full days passed, starting at 0/N.
- Overdue: ≥ N at 00:00 after the deadline.
- Caching and database recording reduce load.
- Test edge cases: holidays, evenings, missing data.
— Editorial Team
No comments yet.