scheduling model

split and calendar math

Updated Apr 22, 2026

How logit stores workout dates as normalized day values, defines today in Pacific time, and builds Monday-first weeks and month grids.

1. Date-only storage without timezone drift

logit treats workout dates as calendar facts rather than timestamp moments. To keep a date stable across parsing, formatting, and timezone transitions, the stored date is normalized to a UTC-noon value for the intended year, month, and day.

d_{\mathrm{store}} = \operatorname{UTC}(y, m, d, 12{:}00)

Interpretation. The noon anchor keeps date-only records from drifting backward or forward when the surrounding environment crosses local timezone boundaries.

The product then formats and compares these values as normalized dates, not as wall clock times. That is why the schedule behaves like a calendar instead of like a timestamped event log.

2. Pacific "today" and parsed inputs

The app defines today from the Pacific calendar, not from the user's machine locale and not from UTC midnight. This keeps daily scheduling aligned with the product's intended operating timezone.

d_{\mathrm{today}} = \operatorname{dateParts}_{\mathrm{America/Los\ Angeles}}(\text{now})

Interpretation. The current Pacific date is extracted first, and only then converted into the normalized stored-date format.

When a user types an explicit YYYY-MM-DD date, logit preserves that exact calendar value if it parses cleanly. If parsing fails, the system falls back to the current normalized date rather than leaving the schedule in an undefined state.

3. Monday-first week and month-grid construction

Weeks start on Monday throughout the product. The dashboard's weekly summaries and the calendar grid both derive their start point from the same Monday-first rule.

\mathrm{offset} = (\mathrm{utcDay} + 6) \bmod 7

Interpretation. Sunday becomes offset six, Monday becomes offset zero, and every other weekday lands between them. The calendar grid then walks forward from the computed Monday start.

Month views use the same logic. The grid starts on the Monday that contains the first day of the month and extends to a fixed forty-two-day layout so the visual calendar stays structurally stable across months.

4. Split normalization and weekday integrity

A split is never stored as a partial or ambiguously ordered week. Incoming split payloads are normalized into a complete Monday-through-Sunday template. Missing days become explicit rest days, duplicate weekdays are rejected, and the final template is sorted into weekday order.

\mathrm{splitWeek} = \operatorname{sort}\!\left(\mathrm{providedDays} \cup \mathrm{defaultRestDays}\right)

Interpretation. The saved split is always a seven-day object with one slot per weekday. Structural ambiguity is removed before persistence.

Condition	Normalization result
Missing weekday	Filled as a Rest day with no exercises
Duplicate weekday	Rejected before the split can be saved
Out-of-order weekdays	Sorted back into Monday-through-Sunday order
Blank split name	Falls back to "Weekly Split"

5. Rest-day enforcement and preload logic

Once the split is normalized, it becomes actionable. If the selected day is a rest day, the logger is disabled for that date and workout creation is rejected. If the day is active, the logger preloads the configured workout type and exercise rows so the user starts from the planned template rather than from an empty form.

The same split seed also drives today's plan on the dashboard: no split yields a setup prompt, a rest day yields a recovery label, and an active day yields the count of planned exercises and the sets they add up to.