E2.14.1time-granularity match设计
时间粒度应与业务需要一致
别名: 时间选择粒度 · minute step · 秒级时间选择
概念解释
时间控件能停在哪一档——整点、五分钟、一分、一秒——叫粒度。业务真正区分的最小间隔应与这一档对齐：会议室按 15 或 30 分钟排，火车按时刻表的分，实验室记录才要秒。粒度比业务粗，合法时间夹在两档之间选不到；比业务细，人要在没有意义的档里滚很久。它管的是一档代表多长，不是时段跨不过午夜，也不是上午下午怎么写。
机制
人把「下一档」理解成「下一件有意义的事」。会议从 10:00 到 10:07 在大多数日历里不是一个可订的槽，提供分钟滚轮就是在提供不会被接受的值，提交后再被咬合到 10:15，刚才的精细是假的。反之，航班 14:03 起飞，粒度 5 分钟会强迫选 14:00 或 14:05，和时刻表冲突。粒度还决定滚轮或列表的长度：一秒一档是 86400 个选项，扫视崩溃。匹配发生在业务调度规则上，不是在「时间能有多精确」的抽象上。
边界
同一产品里不同任务粒度不同：预约 30 分钟，提醒可以要到分。用一个全局时间控件会错配其中一侧。时区转换会把整点变成带分的地方时，目标时区的粒度要以转换后为准。用户键入了更细的值（10:07），若业务禁止，应说明会被对齐到哪一档，而不是静默改掉。秒表、音频剪辑这类真要到秒或毫秒的任务，粗粒度才是错的。
怎么落地
- 按可调度的最小间隔设档：会议室 15/30 分，公共交通按时刻表，提醒按分，媒体剪辑按秒。
- 让界面能选到的值都是提交后仍会被接受的值，不要提供随后被对齐掉的假精度。
- 键入比档更细的值时，明确说出将对齐到哪一档。
- 验证：列出业务真实出现的时间点，看控件能否恰好落到；再试一个业务不承认的中间点，看是无法选择，还是能选却在提交后消失。