Problem
An intermediate-level logical data bug exists in how task deadlines and study plan schedules are evaluated. The application compares task completion dates and upcoming deadlines using raw string values or un-normalized local Date objects instead of universal timestamps (like UTC or epoch milliseconds).
Current Behavior
If a user sets a study goal, the frontend logic calculates the countdown or "overdue" status based entirely on their machine's local timezone configuration. This creates data sync mutations, where a task can prematurely flag itself as "Overdue" or completely skip a scheduled study block depending on the user's regional timezone offset.
Expected Behavior
All deadline evaluations, calendar schedules, and date comparisons should normalize dates to a standard format (like UTC ISO strings or raw epoch numbers) before executing conditional checks, ensuring the UI renders identically regardless of local client machine offsets.
Steps to Reproduce
- Go to the study planner dashboard page.
- Click on create a new study plan objective or task with a deadline set close to midnight.
- Change your local computer system's timezone settings (e.g., switch from IST to EST) and refresh the page.
- See error: The task status miscalculates the remaining time, showing an incorrect scheduling window or flagging active tasks as expired.
Screenshots
N/A
Environment
- Browser: All Modern Web Browsers (e.g., Chrome, Firefox, Safari)
- Version: Latest
Additional Context
Fixing this will involve adding a utility function or adjusting the comparison logic to ensure all client-side dates are evaluated against a standardized timestamp. I would love to tackle this under GSSoC 2026.
Problem
An intermediate-level logical data bug exists in how task deadlines and study plan schedules are evaluated. The application compares task completion dates and upcoming deadlines using raw string values or un-normalized local
Dateobjects instead of universal timestamps (like UTC or epoch milliseconds).Current Behavior
If a user sets a study goal, the frontend logic calculates the countdown or "overdue" status based entirely on their machine's local timezone configuration. This creates data sync mutations, where a task can prematurely flag itself as "Overdue" or completely skip a scheduled study block depending on the user's regional timezone offset.
Expected Behavior
All deadline evaluations, calendar schedules, and date comparisons should normalize dates to a standard format (like UTC ISO strings or raw epoch numbers) before executing conditional checks, ensuring the UI renders identically regardless of local client machine offsets.
Steps to Reproduce
Screenshots
N/A
Environment
Additional Context
Fixing this will involve adding a utility function or adjusting the comparison logic to ensure all client-side dates are evaluated against a standardized timestamp. I would love to tackle this under GSSoC 2026.