数字与日期工具经常只有几行调用，但边界错误会直接进入报表和业务判断。阅读 Nutz 1.b.53 的 Nums、Times 时，我更关注范围、时间基准与并发，而不是根据类的行数判断它们是否重要。
闰年规则要明确历法
Times.leapYear 使用公历常见的整除规则：能被 4 整除，世纪年还需要能被 400 整除。可以用 1900、2000 和普通闰年分别验证，而不是只用一个能被 4 整除的年份。
System.out.println(Times.leapYear(1900)); // false
System.out.println(Times.leapYear(2000)); // true
片段导入 org.nutz.lang.Times。涉及历史日期和其他历法时，应另行确认业务定义，不把一条公历规则推广到所有时间表达。
格式化器的所有权
这个版本的 format(DateFormat, Date) 和 parse(DateFormat, String) 会克隆传入的 DateFormat 后使用，字符串模式重载则创建新的 SimpleDateFormat。这个实现细节比笼统说“底层用了 SimpleDateFormat”更有意义：共享一个可变格式化器与每次使用独立实例，并发行为不同。
调用方仍应避免在克隆同时修改原格式化器。日期模式使用 yyyy 与 YYYY 也有不同含义，时区和 Locale 不能依赖部署机器恰好的默认值。
毫秒时长不是日历运算
一天的固定毫秒数适合表达某些持续时间，却不能直接等价于所有时区中的“下一个自然日”。夏令时、月长和周起始规则会影响区间计算；开始与结束是闭区间还是半开区间，也要与查询条件一致。
Nums 的解析、拼接和范围操作则要检查溢出、符号及输入格式。对金额、计数和 ID 采用不同类型，不把通用数字转换当成业务精度处理。