Make the snooze presets configurable (morning hour, evening hour, quick offsets)

[Ashkaan]

Problem

The five snooze presets are hardcoded. resolveSnoozePresets(now) in packages/client-runtime/src/state/threadSettled.ts takes only the current time — there is no settings input — and the wake times come from three module constants:

const HOUR_MS = 60 * 60 * 1_000;
const EVENING_HOUR = 18;
const MORNING_HOUR = 9;

So "This evening" is always 18:00, "Tomorrow" and "Next week" are always 09:00, and the two relative presets are always +1h and +3h.

Those are reasonable defaults, but they are a guess about someone's day. If your day starts at 07:00, "Tomorrow" wakes every thread two hours after you needed it. If you work until 20:00, "This evening" fires mid-afternoon while you are still in the thread it woke. Snoozing is a per-thread action you take many times a day, so a preset that is two hours off is two hours off every single time — and the only workaround today is to stop using the preset.

Proposal

Let the preset times come from settings, keeping the menu itself exactly as it is:

• Morning hour (drives Tomorrow and Next week) — default 9
• Evening hour (drives This evening) — default 18
• The two quick offsets (In 1 hour / In 3 hours) — default 1h and 3h

The labels should stay derived from the configured values, which they already are: whenLabel is formatted from the resolved Date, so a 07:00 morning hour renders "Tomorrow — 7:00 AM" with no extra work. The same is true of the two rules that hide a preset — "This evening" only appears while it is more than an hour out, and "Next week" collapses when it lands on the same instant as "Tomorrow" (the Sunday case from #8740). Both compare resolved times rather than constants, so they keep working against configured values without changes.

The preset ids are already a closed union:

export type SnoozePresetId = "hour" | "three-hours" | "evening" | "tomorrow" | "next-week";

which gives config a stable key per preset without inventing new identity for them.

Scope

This looks client-side only. thread.snooze already accepts an arbitrary ISO snoozedUntil and the server already validates it, so no protocol, persistence, or server change is implied. Because presets resolve in shared client-runtime, threading settings into resolveSnoozePresets should reach web, desktop, iOS, and Android from one place.

Relationship to the custom-time proposals

This is not #11210 (and not PR #6082), and neither one subsumes the other:

• A custom date/time picker answers "this particular thread, until Friday at 14:30" — an exception, chosen per snooze.
• Configurable presets answer "my morning is 07:00, always" — the default, chosen once.

Someone whose morning is 07:00 does not want to open a picker every time they snooze a thread to tomorrow. The two features complement each other, and configurable presets are the smaller change of the two.

---

Prepared by Claude Opus 5 on behalf of @Ashkaan, from a read of threadSettled.ts on main (client 0.0.40).

[MaxiAschenbrenner]

would love to have this as an option!

[NicoM701]

The original proposal changes hours and offsets for the fixed entries. I would like to extend that to a Snooze presets list in Settings where users can add, edit and delete entries, including built-in choices, with a preview of each entry's next wake date and time.

My use case is changing Next week from Monday 09:00 to Monday 07:00 while keeping Tomorrow at 09:00, removing This evening, and adding reusable durations such as 6h and 12h. Currently, the morning hour couples Tomorrow and Next week. Next week would retain its current local-time behavior: on Monday it targets the following Monday.

I found #18947 directing this request here, the closed proposals #15934 and #15679, and the open duration-favorites PR #16362. There is overlap with favorites, and I want to avoid competing work. I understand #15934 requires maintainer scope agreement before reconsideration. Defaults would stay unchanged until configured, with Restore defaults and Custom available for one-off times. Preset edits would not change wake times already saved on threads.

Would maintainers welcome a contribution for this full editable list, prefer a specific smaller scope, or decline the idea? I will wait for direction before implementing it.

[jeroenev]

For me I have specific projects I work on on specific days
I have project A on tuesday and thursday, a bunch of projects on monday, wednesday and friday, and a few side-projects I only work on in the weekends.
So I currently patch in "Next monday", "Next Tuesday", "Next wednesday" -> "Next Sunday" in the hardcoded list every time I update t3code nightly

[jeroenev]

I'm guessing something even more awesome would be visibility hours where certain projects automatically become visible / invisible (behind a collapsed section) depending on the preset days of the week, but I guess that would add complexity and cause confusion for some users? not sure, would be nice tho

[juliusmarminge]

Closing: current main already covers this as of 93a9e079b1. If you still see it on a build that includes that commit, reply and we'll reopen.