陈冠男1. 先别急着写pattern：XSD日期时间到底管什么
做XML数据处理的人，迟早会在日期时间上栽一次跟头。我自己第一次遇到这类问题是在一个数据交换项目里，对方系统返回的报文里时间字段长这样：2024-08-15T09:30:00+08:00。我当时想，这不就是一个带时区的字符串嘛，用校验规则匹配一下不就行了。结果一校验，报错；去掉时区，报错；把T换成空格，还是报错。最后查了XML Schema规范才明白，日期时间类型在XSD里是一整套独立的值空间和词法表示规则，跟大多数编程语言里DateTime对象的概念完全不是一回事。
XML Schema（也就是XSD）提供了一组内置的日期时间相关类型，覆盖了日期、时刻、持续时长、以及单独的年、月、日等维度。它们的词法格式基本遵循ISO 8601，但又有自己的严格约束。很多人以为"日期时间类型"就是指dateTime这一个类型，实际上XSD里日期时间这个家族一共有十个左右的内置类型，各自有各自的合法格式和使用边界。
这篇文章我想把这个家族完整拆一遍，重点说清楚三个层面的问题：每种类型合法的字符串长什么样；解析和校验时会踩哪些坑；以及实际项目中怎么选型、怎么处理时区、怎么跟数据库和编程语言互操作。适合正在做XML报文校验、数据交换接口、或者写XML Schema校验规则的同学参考，也适合那些只想搞懂"为什么这个日期字符串校验不过"的人。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. dateTime：最常用也最容易踩坑的主力类型
2.1 合法格式的完整拆解
xsd:dateTime是整个家族里最有存在感的类型，它表示"日期 + 时刻"的组合。完整的词法格式是：
code复制YYYY-MM-DDThh:mm:ss
注意几个硬性要求：
- 年必须是四位（XSD 1.0中，超出四位其实也是允许的，但必须有符号扩展，见后文）。
- 月、日、时、分、秒都必须用两位数字表示，
2024-1-1T10:30:00是非法格式。 - 日期和时间之间必须用大写的
T分隔，不能是空格。 - 秒是整数，但允许在秒后面跟小数点表示小数秒，比如
2024-08-15T09:30:00.123。
这里有个很多人第一次接触时会忽略的点：小数秒的位数是任意的，.1、.123、.123456789都合法，但小数点后不能为空，也就是09:30:00.是不合法的。
从值空间（value space）的角度来说，dateTime表示的是时间轴上的一个瞬时点。但这里有个微妙之处：如果字符串不带时区，它表示的并不是某个绝对时刻，而是本地时间语义下的那个点。这个点在转换成UTC时的具体偏移是不确定的，需要依赖处理上下文。这个概念直接关系到后面要讲的时区处理。
2.2 时区的三态问题：带不带时区是两码事
XSD里的时区不是可选的装饰，而是影响类型语义的关键部分。一个dateTime字符串可以有三种情况：
- 显式UTC：末尾用
Z表示，如2024-08-15T09:30:00Z。 - 显式偏移：末尾用
+hh:mm或-hh:mm表示，如2024-08-15T09:30:00+08:00。 - 无时区：末尾啥都不带，如
2024-08-15T09:30:00。
无时区的情况，在XSD 1.0里被直接叫做"无时区"（no timezone），它不等于UTC，也不等于本地时区，而是一种"未知时区"状态。当你拿一个带时区和一个不带时区的时间做比较时，XSD 1.0的规则是：两者不可比较。不是"假定为UTC再比较"，也不是"假定为本地时间再比较"，而是直接告诉你：比较不了。
我在实际项目里就遇到过这个问题。两个系统各存一个dateTime字段，一个是从数据库读出来拼的，带了系统默认时区偏移；另一个是前端直接传的字符串，没带时区。到了校验和排序阶段，结果根本不按预期走。最后统一约定：传输层一律使用带UTC偏移的格式，入库前统一转换成UTC。这个约定从源头解决了时区状态不一致的问题。
2.3 那些年我见过的非法dateTime
以下是我在实际项目中亲眼见过的非法dateTime，以及它们为什么非法：
| 字符串 | 问题 | 原因 |
|---|---|---|
| `2024-8-15 |