Problem
Recurrence and scheduling calculations (recurring task instances, "today"/"scheduled"
filtering, day-rollover behavior) implicitly assume a day boundary at local midnight.
That assumption doesn't hold for anyone on a non-diurnal schedule, e.g. a night-shift
worker whose "day" runs roughly 21:00–08:00. For that user, a "daily" recurring task
rolling over at midnight local time resets mid-shift, while they're still actively
working the day the task was scheduled for.
Current spec behavior
The spec currently states tools "MUST document timestamp precision and timezone
behavior," but stops there, it doesn't define day-boundary semantics for recurrence,
and doesn't provide a mechanism for a collection or user to declare a non-default
day boundary.
Proposed change
Add an optional, spec-level field (collection-level in mdbase.yaml, e.g. something
like day_start_offset or day_boundary) that recurrence/scheduling calculations
use as the effective day boundary instead of assuming midnight-local. Default
behavior (midnight) stays unchanged when the field is absent, so this is additive
and backward-compatible with existing v0.2/v0.3 collections.
Conformant implementations that compute "today," recurrence rollover, or
scheduled-date filtering would read this value instead of hardcoding midnight.
Prior art — this isn't a one-off request
Given mdbase is meant to be the shared interoperability layer across TaskNotes,
mtn, and future implementations, this seems like the right layer to solve it once
rather than have every downstream tool reinvent (or skip) it individually.
Problem
Recurrence and scheduling calculations (recurring task instances, "today"/"scheduled"
filtering, day-rollover behavior) implicitly assume a day boundary at local midnight.
That assumption doesn't hold for anyone on a non-diurnal schedule, e.g. a night-shift
worker whose "day" runs roughly 21:00–08:00. For that user, a "daily" recurring task
rolling over at midnight local time resets mid-shift, while they're still actively
working the day the task was scheduled for.
Current spec behavior
The spec currently states tools "MUST document timestamp precision and timezone
behavior," but stops there, it doesn't define day-boundary semantics for recurrence,
and doesn't provide a mechanism for a collection or user to declare a non-default
day boundary.
Proposed change
Add an optional, spec-level field (collection-level in
mdbase.yaml, e.g. somethinglike
day_start_offsetorday_boundary) that recurrence/scheduling calculationsuse as the effective day boundary instead of assuming midnight-local. Default
behavior (midnight) stays unchanged when the field is absent, so this is additive
and backward-compatible with existing v0.2/v0.3 collections.
Conformant implementations that compute "today," recurrence rollover, or
scheduled-date filtering would read this value instead of hardcoding midnight.
Prior art — this isn't a one-off request
"Allow Users to Define Start of Day for Task Completion and Recurrence"
Allow Users to Define Start of Day for Task Completion and Recurrence obsidian-tasks-group/obsidian-tasks#3395
and timezone pain independently: [Bug]: Recurring daily tasks remain visually completed after new day starts callumalpass/tasknotes#521 and
Tension with recurring tasks callumalpass/tasknotes#237 (discussion)
Given mdbase is meant to be the shared interoperability layer across TaskNotes,
mtn, and future implementations, this seems like the right layer to solve it once
rather than have every downstream tool reinvent (or skip) it individually.