BC
Brad CodyAdministrator
Current product→Shared components and patterns
Reverse spec drafted

Date, time and date-range picker

Date-only, local time, timestamp, range and timezone-aware scheduling controls.

Observed routeShared componentFuture Spec 16 →
Current maturityReusable pattern identified; canonical component contract required
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

Date, time and date-range picker appears across the current product but is not yet governed as one fully documented reusable component. Native date inputs appear for Tasks and Project Opportunities, while future Calendar, delivery and scheduling work needs time, range and timezone behavior.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Canonical interactionChoose date-only, local date-time, absolute timestamp or range explicitly. Show the effective timezone beside timed values and handle daylight-saving transitions. Allow typed input and calendar selection, include clear/today actions where appropriate, and validate start/end ordering.Required reusable contract
Data contractStore date-only as a date; timed events as UTC instant plus IANA timezone and original local values; ranges store explicit inclusive/exclusive semantics.Required shared storage and API behavior
AccessibilityKeyboard entry must remain possible; calendar grid has correct roles, focus movement and announced selected/current dates.Required before component is approved for reuse
Reuse inventoryTask due dates, Project milestones, availability, credentials, expected arrivals, receiving, delivery and installation, CalendarKnown current and future consumers
Current inconsistenciesCurrent controls often capture date only. Timezone and all-day semantics are unclear. No shared date-range, recurrence or business-day control is evidenced.Observed or identified correction work

User journeys

Current flows

01

Use Date, time and date-range picker

  1. Render from the shared component registry
  2. Load canonical value and configuration
  3. Accept keyboard, pointer or assistive-technology input
  4. Validate and normalize
  5. Persist canonical value with provenance
  6. Render the same meaning in profiles, grids, filters, exports and integrations
Observed result

This is the required cross-product journey; implementation consistency varies today.

State model

Current and expected states

Default

Value can be entered or selected with a visible label.

Focused

Must provide a visible focus indicator without layout shift.

Disabled or read-only

Must distinguish unavailable input from view-only canonical value.

Required or optional

Requirement is communicated in label, schema and validation—not colour alone.

Invalid or warning

Inline message explains the problem and preserves the user’s input where safe.

Loading or saving

Async work prevents duplicate commands and remains announced.

Empty or cleared

Null, empty string, zero and empty collection retain distinct meanings.

Product rules

Non-negotiable boundaries

  • Build once and reuse the same component, schema and formatter in every Workspace experience.
  • Display formatting is separate from canonical storage.
  • Every value has a stable field key, type, validation, privacy classification and version.
  • Client validation improves usability; server validation remains authoritative.
  • Equivalent values render consistently in forms, grids, profiles, filters, exports, notifications and documents.
  • Choose date-only, local date-time, absolute timestamp or range explicitly.
  • Show the effective timezone beside timed values and handle daylight-saving transitions.
  • Allow typed input and calendar selection, include clear/today actions where appropriate, and validate start/end ordering.
Dependencies
Spec 16 Design System and Reusable ComponentsShared field registryDesign tokensDynamic formsPermissionsLocalization and accessibility testing

Known current limitations · 3 mapped

What is missing, broken or unverified

Future Spec 16 owns closure →
  1. Current controls often capture date only.
  2. Timezone and all-day semantics are unclear.
  3. No shared date-range, recurrence or business-day control is evidenced.

Future alignment

Required evolution

  • 01Promote this pattern into the approved component library.
  • 02Replace local copies incrementally and retain migration adapters only where required.
  • 03Add automated interaction, validation, accessibility and serialization tests.
  • 04Track reuse across: Task due dates, Project milestones, availability, credentials, expected arrivals, receiving, delivery and installation, Calendar.

Current baseline

Acceptance record

  • The component has one public API and canonical data contract.
  • All required states are documented and tested.
  • Formatting and validation are consistent across every consumer.
  • Keyboard and screen-reader testing passes.
  • Existing inconsistent copies have an owner and migration plan.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented
← Feature inventoryOpen Future Spec 16 →