填写生日时，用户通常已经知道答案；预约会议室时，他需要查看哪天、哪段时间可用。日期时间选择器应先按这两类任务选择输入方式，再定义起止范围、禁选原因和时区。把所有日期都放进同一种日历，容易让简单输入变成反复翻月，也容易遗漏真正重要的业务限制。
用户在回忆日期，还是安排日程
日期控件的选择，首先取决于用户是否需要看日期之间的关系。生日、证件上的日期适合直接输入；安排培训、预约服务时，星期、可用时段与相邻日期会影响决定，日历更有帮助。查询某月记录，则不必要求用户补出没有业务意义的具体日子。
| 用户任务 | 合适的起点 | 重点确认 |
|---|---|---|
| 填写已知日期 | 可直接输入的日期字段 | 格式清楚，能快速修改年月日 |
| 选择近期预约 | 日历与可用时段 | 哪天可选，以及为什么不可选 |
| 查询一段时间 | 起止范围，可补常用快捷项 | 是否包含结束日期，使用哪个时区 |
| 记录大概月份 | 年、月粒度 | 允许的精度，不强迫用户编一个日期 |
Carbon日期选择器指南同样区分易记日期与日程安排，并建议日历保留直接输入途径。手动输入能帮助熟悉日期的用户，但不能仅靠占位符说明格式；开始输入后，格式提示仍应可见。
“2026-11-12”通常比“11/12/26”更少歧义。具体采用什么格式要结合目标地区，界面上的格式、帮助文字与错误示例应一致。日期没有时刻含义时，不要无端给生日或账单月份附上时区。
起止范围要写清是否包含边界
“截至10月20日”和“10月20日结束”可能被理解为不同时间。报表筛选、活动报名、房间预约也不一定采用相同规则：筛选往往按日期范围理解，预约则需要确定结束时刻之后资源何时重新可用。
以培训室预约为例，下面约定：显示北京时间，使用24小时制；本例只安排当天使用，开放时段为09:00—18:00；开始、结束时间以30分钟为步长，结束必须晚于开始。这是一组示例业务规则，实际产品应替换为自己的开放时间与粒度。
| 规则项 | 本例定义 | 界面应表达什么 |
|---|---|---|
| 当前选择 | 2026年10月20日，14:00—15:30 | 起止标签完整，明确北京时间 |
| 边界 | 本次预约结束后，下次可以在15:30开始 | 可用时段与冲突提示遵守同一规则 |
| 结束时间 | 必须晚于开始，且不超过18:00 | 说明具体冲突，不只标红 |
| 跨日 | 本例不支持跨日 | 解释需分开预约，不能悄悄改日期 |
| 可用性 | 选择时展示状态，提交时再次确认 | 选中不等于已经预留成功 |
同一天预约不需要两套完整的日期字段，可以用一个日期加起止时间，减少不必要的重复。若产品需要跨日范围，则必须让两个日期都可见；例如“10月20日23:30—10月21日00:30”，不能只显示两个时刻让用户猜测。
改了开始时间，结束时间怎么办
原选择为14:00—15:30。用户把开始改到16:00，旧结束时间已失效。常见处理有保留时长自动顺延、清空结束时间让用户重选，或保留数值但清楚提示冲突。三种方式都需要结合任务判断，不应由控件默认行为替团队决定。
在本例中，可以约定把结束时间清空，并提示“开始时间已调整，请重新选择结束时间”。这样用户能够重新考虑会议时长。若采用保持原时长的方式，就要显式展示新结果；顺延到营业时间之外时，应停止自动调整并解释限制，不能把结束时间偷偷截短。
输入中的暂时不完整也不同于最终错误。用户正在把“14:00”改成“16:00”时，不宜每删除一个字符就弹出全局警告。离开字段或提交时再检查完整规则，错误贴近对应字段，并保留其他选择。基础文案可参照表单标签与错误提示。
灰掉日期之前，先确定用户需要知道什么
过去日期、尚未开放、当天已约满和系统暂时无法确认，是不同原因。前几类可以作为不可选状态，最后一类是信息获取失败；如果都灰掉，用户会把服务故障理解为没有空位。
- 超出可预约范围：在日历旁说明范围，例如“可预约未来30天”，同时确定是否包含今天。
- 当天已约满：说明没有可用时段；如果支持候补或其他场地，可提供相关入口。
- 部分时段被占用：当天仍可选，在时段列表中标明占用，不要让用户先完成整张表才发现冲突。
- 可用性获取失败：保留用户已选日期，显示无法加载时段和重试入口，不伪装成全部约满。
禁选原因不能只依赖鼠标悬停。移动端没有同等的悬停体验，可以在日期范围说明、可读图例或选择后的就近反馈中说明。若某些不可选日期无法获得焦点，也不能把关键原因仅放在那些格子的提示里。
需要时刻的任务，把时区放到用户能确认的位置
预约对象固定在北京，可以写“北京时间（UTC+8）”。如果产品按用户所在地显示，则确认信息应让双方知道指的是哪一个时区。同一绝对时刻换时区显示，和保持“当地14:00”不变，是两种不同操作，必须先确定业务含义。
例如跨国线上培训原定北京时间10月20日21:00。用户切换时区只是为了阅读时，应改变显示而不是改变实际开始时刻。对于每周当地上午9点的重复日程，则还涉及当地时区规则及夏令时，不能简单加减固定小时数。是否支持此类日程，应在需求中明确，本例培训室预约不处理重复规则。
一张可复制的时间规则表可以包含：业务时区、显示格式、起止是否包含边界、最小粒度、开放区间、默认值来源、修改起点后的处理、跨日限制、可用性失效后的处理。研发接到的是这些规则，才有可能让日历、列表和确认页显示同一个时间含义。
在原型里检查选择过程，而不只检查日历外观
在墨刀原型中，可以先搭培训室预约表单，再建立日历展开、时间已选、结束时间失效、时段被占用和预约确认页。沿用“2026年10月20日14:00—15:30”这份资料，让连线经过选择、修改和确认，团队更容易发现不同页面的时间不一致。
先让评审者选中这段时间，再把开始改到16:00；预期是结束字段按约定清空，而不是留下15:30仍允许提交。之后演示“时段已被他人预约”的结果，原选择仍应可见，并给出重新选择入口。日历上的可用状态只是选择时的快照，真正预约成功需要提交结果确认。
键盘操作也要在交付说明中写明：怎样进入日历、怎样移动和选择日期、关闭后焦点回到哪里。W3C提供了日期选择弹窗示例，可作为实现参考；原型能够演示路径，不意味着最终代码已完成辅助技术适配。
完成评审时，不妨读一遍确认页上的日期、起止时间与时区，再回到列表查同一条预约。若用户无需猜测边界含义，也能从无效选择返回可用时段，这个日期选择流程才具备清楚的交付依据。
