Slack Block Kit Date & Time Picker Constraints Prompt
Design Block Kit datepicker/timepicker/datetimepicker inputs with min/max bounds, timezone handling, and validation for ops scheduling forms.
- Target user
- Platform engineers building Slack scheduling and maintenance-window forms
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has shipped dozens of Slack scheduling forms and learned every sharp edge of Block Kit's date and time picker elements the hard way. I will provide: - The scheduling use case ([maintenance window / deploy freeze / on-call swap / change request]) - The fields users must pick (date, time, datetime, duration) - Constraints (no past dates, business hours only, max N days out, [TEAM TIMEZONE POLICY]) - Whether the form is a modal `view` or an in-message `input` block Your job: 1. **Element selection** — decide between `datepicker`, `timepicker`, and `datetimepicker`. Explain the tradeoffs: - `datetimepicker` returns a Unix timestamp (timezone-safe) but renders as one combined control - separate `datepicker` + `timepicker` are friendlier but you must reassemble them and resolve the user's timezone yourself 2. **Constraint wiring** — set `initial_date`, `min`/`max` where supported, and `placeholder`. Note which constraints Block Kit enforces client-side versus which you MUST re-validate server-side (Block Kit does NOT block past `datepicker` dates). 3. **Timezone resolution** — show how to read the submitting user's `tz` from `users.info` and convert picked values to UTC for storage. Flag the daylight-saving edge cases. 4. **Server-side validation** — return Block Kit `response_action: "errors"` keyed to the offending `block_id` for: past dates, out-of-window times, end-before-start, duration over limit. 5. **Block Kit JSON** — a complete, valid `blocks` array for the modal, with `block_id` and `action_id` on every input. 6. **Handler pseudocode** — extracting values from `view.state.values`, reassembling, validating, and re-rendering with errors. Output as: (a) element-selection rationale, (b) constraint table (client vs server enforced), (c) timezone-resolution snippet, (d) complete Block Kit JSON, (e) validation handler pseudocode, (f) test matrix for edge cases. Safety: never trust client-supplied dates; re-validate every value server-side before scheduling any action.
Why this prompt works
Block Kit’s date and time elements look trivial until you ship one, at which point you discover that the client-side affordances are inconsistent across desktop, mobile, and web, and that none of them save you from re-validating on the server. This prompt forces the model to separate what the UI enforces from what your handler must enforce — the single most common source of scheduling bugs in Slack ops tooling. By demanding a constraint table that explicitly labels each rule as client- or server-enforced, it produces output you can actually trust against a real workspace.
The prompt also pins down the timezone problem before it bites you. A datepicker plus a timepicker gives you a wall-clock value with no timezone attached, and the difference between “2 PM the submitter’s time” and “2 PM workspace default” is the difference between a maintenance window that lands and one that pages the wrong continent at the wrong hour. Requiring explicit users.info timezone resolution and UTC storage makes the AI confront daylight-saving boundaries instead of glossing over them.
Finally, by asking for response_action: "errors" keyed to block_id, the output integrates with Slack’s native modal error surface rather than dumping a generic failure message. That keeps the human reviewer in the loop on validation logic while the AI handles the tedious JSON, which is exactly the division of labor that makes AI-drafted Block Kit safe to ship.