laydate的value字符串是本地时区格式化结果，不含时区标识，非UTC时间；须用new Date(value).toISOString()转为标准UTC字符串，range模式需分别处理起止时间。
不能直接用 laydate 内置方法转 UTC，它所有时间处理都基于本地时区；必须手动解析输入值、转成 Date 实例后调用 toISOString() 截取 —— 否则会把本地时间误当 UTC 存储或传输。
为什么 value 字符串不是 UTC 时间
laydate 的 done 回调返回的 value（如 "2026-10-02 06:03:00"）是按用户本地时区格式化的字符串，不带时区标识。它不代表 UTC，也不等于服务器期望的 ISO 时间。直接传给后端或存入数据库，会导致时差错乱（比如北京时间上午 9 点存成 "2026-10-02T09:00:00"，实际应是 "2026-10-02T01:00:00Z"）。
- 不要对
value字符串做简单替换（如加Z或改T），那是伪造 UTC - 不要用
new Date(value).toUTCString()，它返回的是可读字符串，不是标准 ISO 格式 - 若
type: 'date'，value只有年月日，需补" 00:00:00"才能构造完整时间点
正确转为 UTC 的三步操作
核心是：先还原为本地时间点 → 转成毫秒时间戳 → 交给 Date.prototype.toISOString() 自动对齐 UTC。
- 用
new Date(value)解析value字符串（确保value非空且含完整时间，否则补零） - 调用
.toISOString()，它天然返回YYYY-MM-DDTHH:mm:ss.sssZ格式，精确到毫秒且带Z - 如只需秒级精度，用
.toISOString().slice(0, 19) + "Z"（避免毫秒部分干扰）
示例：
done: function(value, date, endDate) {
if (!value) return;
// 补全时间部分（type: 'date' 时 value 不含时分秒）
const fullValue = value.includes(':') ? value : value + ' 00:00:00';
const utcStr = new Date(fullValue).toISOString().slice(0, 19) + 'Z';
console.log(utcStr); // e.g. "2026-10-02T06:03:00Z"
}
range 模式下要分别处理起止时间
双日期场景中，value 是类似 "2026-10-02 - 2026-10-05" 的字符串，dates 参数（v5.1+）更可靠：
- 优先用
dates[0]和dates[1]（两个Date对象），直接调.toISOString() - 若用老版本，需
value.split(' - ')得到两段字符串，每段都补' 00:00:00'再解析 - 注意：分隔符必须是
' - '（空格+短横+空格），否则split失败
服务端接收前最容易忽略的一点
toISOString() 生成的是带 Z 的完整 UTC 时间，但某些后端框架（如 Java 的 LocalDateTime）会拒绝带 Z 的字符串。此时应传 .toISOString().replace('Z', '+00:00')，或由后端统一用 Instant.parse() 处理 —— 别在前端去掉 Z 后当成本地时间解析。
