做数据清洗和接口对接的时间长了你会发现一个特别基础但又绕不开的需求怎么判断一个字符串到底是不是时间格式。用户提交的表单里、合作方导出的文件里、爬虫抓下来的字段里总有人把“2024-01-15”写成“2024/1/15”把“15:30”写成“1530”甚至直接丢一个13位的时间戳过来。今天我把这个常用的Java工具方法完整拆开讲一遍从方案选型到完整实现再到实际踩坑记录一次讲透。1. 工具定位这个字符串判断问题为什么值得单独封装1.1 从实际场景出发谁需要这个工具先说说这个工具到底解决什么问题。我在之前的业务开发里遇到过这么几个场景文件导入模块需要从Excel或CSV里解析大量日期字段但每一行数据格式都不一样有的是“2024-03-08 14:30:00”有的是“2024/03/08”还有的是“2024年3月8日”接口联调时对方文档里写的是标准ISO格式实际传过来的却是“08-Mar-2024”数据库导出排查时某个varchar字段里混着“20240115”这种紧凑格式和“2024-01-15 14:30”这种带空格的格式。这种情况如果每个业务方各写一套判断逻辑代码会很散、很难维护。最合理的做法是沉淀一个独立的工具类统一的入口、统一的格式列表、统一的是否严格解析策略项目里所有涉及时间字符串判定的地方都走这个工具。适合用这个工具的开发者包括写数据清洗和ETL的、做接口对接的、维护导入导出功能的以及任何需要在运行时判断字符串语义的人。1.2 为什么正则表达式救不了你一提到“判断字符串是否是时间格式”很多人第一反应是写正则表达式。比如判断日期就写\d{4}-\d{2}-\d{2}判断时间就写\d{2}:\d{2}:\d{2}。这种方式在两三个固定格式的简单场景下能蒙混过关但只要格式一多就会暴露两个致命问题。第一个问题是正则只能判断“外形”不能判断“语义”。“2024-13-45”完全可以通过\d{4}-\d{2}-\d{2}这个正则但它根本不是一个合法日期同样“2024-02-30”在外形上完美匹配却是个不存在的日期。另一个问题是正则对格式变体的覆盖完全靠人工堆模式每加一种格式就得多写一大段到最后模式串比业务代码还难懂改起来牵一发动全身。真正正确的做法是把判断交给时间解析器。解析器会完整检查年月日时分秒的取值是否合法比如月份在1到12之间、日期在当月天数范围内解析失败就直接判定为非法根本不需要你自己去枚举各种非法组合。1.3 方案选型java.time 的解析能力才是正确答案看番Java技能树的开发者都知道老式SimpleDateFormat已经不太适合新项目了这个问题上我们优先选择java.time包下的DateTimeFormatter和LocalDateTime等类。这里有两个关键理由。首先是线程安全。SimpleDateFormat是线程不安全的多个线程共用一个实例会在内部Calendar状态上打架导致解析出错误结果或者直接抛异常。而DateTimeFormatter是不可变类天然线程安全可以放心地声明成static final常量让整个类共用。其次是严格模式控制。DateTimeFormatter在默认情况下要求字符串严格匹配格式定义年月日数字位数不齐、日期不存在等情况都会抛DateTimeParseException恰好是我们要的“严格校验”效果。当然用java.time不是说完全抛弃正则正则仍然可以作为一个“预筛”环节在解析前快速排除明显不是时间格式的字符串减少不必要的解析尝试。但最终裁决权必须交给解析器。2. 核心细节想清楚「时间格式」到底意味着什么2.1 时间字符串的常见形态动手写代码前先把你可能遇到的所有时间字符串形态盘一遍。我按实际项目中出现的频次做了个分类。第一类是标准日期时间格式也就是yyyy-MM-dd HH:mm:ss及其变体比如2024-03-08 14:30:00。第二类是纯日期格式比如2024-03-08、2024/03/08这类在文件导入中最常见。第三类是紧凑格式包括20240308和20240308143000这种通常从数据库或老旧系统导出。第四类是带时区偏移的 ISO 格式比如2024-03-08T14:30:0008:00这种常见于接口返回体。第五类是时间戳也就是纯数字串可能是10位的秒级时间戳或13位的毫秒级时间戳。在设计工具时我会把日期、时间、日期时间、时间戳分开做判断方法。提供isDate、isTime、isDateTime、isTimestamp等入口这样调用方可以根据字段含义选择最精确的判定而不是笼统地调一个方法。2.2 严格解析与宽松解析的分界线这里有个很容易踩坑的概念解析器有两种模式严格模式和宽松模式。宽松模式下解析器会做一些计算上的“纠正”比如把2024-02-30解析成2024-03-01把2024-13-01解析成下一年的1月1日而不是报错。这显然不是我们想要的行为因为2024-02-30这个字符串本身并不是一个合法的时间格式。DateTimeFormatter默认使用严格解析这对我们是友好的。但要注意通过DateTimeFormatter.ofPattern(yyyy-MM-dd)创建的解析器在严格模式下要求格式定义与字符串一一对应。比如“2024-3-8”这种月份和日期只有一位数字的字符串用yyyy-MM-dd去解析会失败因为模式里的MM代表至少两位数字。如果你想兼容这种写法就得把 pattern 改成yyyy-M-d或者使用DateTimeFormatterBuilder配合parseLenient来放开位数限制。我的建议是工具默认保持严格模式保证判定结果可靠如果某些调用方明确需要容错可以额外提供ALLOW_LOOSE参数或单独的宽松判定方法由调用方自行选择。默认严格是最安全的行为。2.3 特别容易被忽略的格式陷阱YYYY、MM、HH大小写含义写时间格式解析时DateTimeFormatter的 pattern 字母大小写是有严格含义的搞混了会出大问题。这里挑三个最容易翻车的字母说。第一个是yyyy和YYYY的区别。小写y表示“年”大写Y表示“周年”Week-Based-Year。在跨年那一周“2024-12-30”这个日期的周年是2025年。如果解析时用了YYYY-MM-dd返回值会是2025年12月30日业务数据就这么被悄悄改了一年。判断时间格式的工具如果用了YYYY对2024-12-30这种字符串依然会判定为合法但它解析出来的结果已经不对了。第二个是MM和mm的区别。MM是月份mm是分钟。2024-03-08 14:30里的30用mm才正确写成MM会直接报错或者解析出离谱的结果。第三个是HH和hh的区别。HH是24小时制0到23hh是12小时制1到12后面还需要带上a表示上下午。如果你只想支持24小时制格式pattern 里必须用HH。这些细节虽然不影响“判定是否合法”的结果但如果后续要从解析结果里读日期字段、做格式化或比较就会暴露出严重问题。工具类里只使用明确无误的 pattern 字母是职业习惯问题。3. 实操过程一步一步写出可落地的工具类3.1 工具类结构设计接下来把完整实现写出来。这个类我命名为DateParseUtil职责单一只负责“判断一个字符串是否是时间格式”不做格式化、转换、计算等多余的事。类结构上分为四层。常量层存放所有预定义的日期时间 pattern比如yyyy-MM-dd HH:mm:ss、yyyy-MM-dd、yyyy/MM/dd、yyyyMMdd、ISO 时间格式等统一转换为DateTimeFormatter并放入一个不可变列表。判定层提供一系列public static boolean方法内部遍历格式化器列表逐一尝试解析捕获到解析成功且完整消耗整个字符串的情况返回 true。工具层是核心私有方法tryParse它把重复的遍历逻辑收起来。便利层提供isDate、isTime、isDateTime等带业务语义的入口。这种分层的好处是新增一种时间格式时只在常量层追加一条 pattern需要新语义判定时只在入口层增加一个方法。调用方不需要关心内部实现细节。3.2 完整代码实现下面直接上代码。这个类可以直接复制到项目里使用JDK 8 及以上都可以。import java.time.LocalDate; import java.time.LocalDateTime; import java.time.LocalTime; import java.time.format.DateTimeFormatter; import java.time.format.DateTimeParseException; import java.time.temporal.TemporalAccessor; import java.util.ArrayList; import java.util.Arrays; import java.util.List; public class DateParseUtil { private static final ListDateTimeFormatter DATE_FORMATTERS createFormatters( yyyy-MM-dd, yyyy/MM/dd, yyyyMMdd, yyyy.MM.dd, yyyy年MM月dd日 ); private static final ListDateTimeFormatter TIME_FORMATTERS createFormatters( HH:mm:ss, HH:mm, HHmmss ); private static final ListDateTimeFormatter DATE_TIME_FORMATTERS createFormatters( yyyy-MM-dd HH:mm:ss, yyyy-MM-dd HH:mm, yyyy/MM/dd HH:mm:ss, yyyy-MM-ddTHH:mm:ss, yyyy-MM-ddTHH:mm:ssXXX, yyyy-MM-ddTHH:mm:ss.SSSXXX, yyyyMMddHHmmss ); private static ListDateTimeFormatter createFormatters(String... patterns) { ListDateTimeFormatter list new ArrayList(); for (String pattern : patterns) { list.add(DateTimeFormatter.ofPattern(pattern)); } return list; } private DateParseUtil() { // 工具类不允许实例化 } public static boolean isDateTime(String str) { return isType(str, DATE_TIME_FORMATTERS); } public static boolean isDate(String str) { return isType(str, DATE_FORMATTERS); } public static boolean isTime(String str) { return isType(str, TIME_FORMATTERS); } public static boolean isTimestamp(String str) { if (str null || str.isEmpty()) { return false; } if (!str.chars().allMatch(Character::isDigit)) { return false; } try { long value Long.parseLong(str); // 粗略判断10位为秒级时间戳13位为毫秒级时间戳 long lowerBound 8; // 100000000 秒约1973年 long upperBound 13; int digitCount str.length(); if (digitCount 10) { return value lowerBound value 10000000000L; } else if (digitCount 13) { return value 1000000000000L lowerBound * 1000L value 10000000000000L; } return false; } catch (NumberFormatException e) { return false; } } public static boolean isDateTimeOrDate(String str) { return isDateTime(str) || isDate(str); } private static boolean isType(String str, ListDateTimeFormatter formatters) { if (str null || str.trim().isEmpty()) { return false; } String input str.trim(); for (DateTimeFormatter formatter : formatters) { try { TemporalAccessor parsed formatter.parse(input); if (parsed ! null) { return true; } } catch (DateTimeParseException e) { // 未匹配继续尝试下一种格式 } } return false; } public static void main(String[] args) { String[] samples { 2024-03-08, 2024/03/08, 20240308, 2024-03-08 14:30:00, 2024-03-08T14:30:0008:00, 14:30:00, 14:30, 143000, 2023-02-30, 2024-13-01, abcde, 2024-3-8, }; for (String s : samples) { System.out.println(s isDateTimeOrDate(s)); } } }这段代码有几个设计细节值得说。createFormatters方法把字符串列表转换成DateTimeFormatter列表新增格式时只需要增加一行字符串。isType是判定核心先做空值检查和trim()处理再去遍历解析。formatter.parse(input)如果成功返回TemporalAccessor走到这说明字符串整体完整匹配并且语义合法直接认定 true如果抛DateTimeParseException说明这一种格式匹配不上继续尝试下一种。3.3 关键参数与配置说明这里有几个参数和配置可以按业务需要调整。格式列表是整个工具的灵魂。我上面给的是保守基础版项目里如果还有dd-MM-yyyy、MM/dd/yyyy等欧美习惯格式直接往列表里加。还要注意 pattern 里的空格、T、时区偏移量XXX都要和实际数据完全一致。一个容易忽略的点yyyy-MM-dd HH:mm:ss里的单个空格是普通字符解析时字符串里必须有一个空格如果线上数据是两个空格或者全角空格就会判定失败。这种场景建议在isType里对多个空格做归一化处理。时间戳的判定我写的是粗略但实用的逻辑。10位数字覆盖了从1973年到2286年之间的秒级时间戳13位数字覆盖了毫秒级时间戳。如果业务里出现过16位微秒时间戳可以再加一个长度分支。3.4 使用示例与边界测试我们来跑一下main方法里的样例数据。结果应该是2024-03-08→ true2024/03/08→ true20240308→ true2024-03-08 14:30:00→ true2024-03-08T14:30:0008:00→ true14:30:00→ true14:30→ true143000→ true2023-02-30→ false2024-13-01→ falseabcde→ false2024-3-8→ false→ false几个边界结果简单说明一下2023-02-30判 false 是因为2月30日根本不存在2024-13-01判 false 是因为13月不存在2024-3-8判 false 是因为月份的MM要求至少两位数字如果要兼容这种写法得把 pattern 里的MM改成M。这些结果刚好体现了“解析器做最终裁决”的设计思路。4. 常见问题与排查技巧实录4.1 经典坑点速查表把实际开发和维护中遇到的高频问题整理成一张表排查时可以快速对照。问题现象根源解决方案用YYYY-MM-dd解析把跨年日期算到下一年大小写字母含义搞混pattern 统一使用小写yyyy解析异常的程序突然挂掉没有捕获DateTimeParseException判定方法内部必须捕获该异常多线程下日期解析偶尔出错共用非线程安全的SimpleDateFormat改用DateTimeFormatter全角空格导致解析失败数据里混入不可见字符判定前先做replaceAll(\\s, )2024-02-30被判合法用了宽松解析模式或正则预判确保DateTimeFormatter严格模式4.2 实战中遇到的两个典型故障第一个故障发生在某次批量导入任务里。数据源是一张老旧的业务表日期字段以字符串形式存储长度和格式都比较混乱。导入代码最初用的是SimpleDateFormat加宽松模式结果一批 “2024-02-30” 之类的脏数据被强制修正成新日期写入新库事后对账发现和原库相差了十几天。排查半天才发现是解析器在宽松模式下做了日期溢出自动进位。后来换成严格的DateTimeFormatter这类问题就再也没出现过。第二个故障是时区偏移被默认吞掉。某接口返回的字段是2024-03-08T14:30:0008:00判定工具返回了 true但后续转换时想取出LocalDateTime发现结果里竟然没有时区偏移信息。原因是DateTimeFormatter.ofPattern(yyyy-MM-ddTHH:mm:ss)只能解析没有时区的那一部分。如果要保留时区信息必须用带XXX的 pattern或者直接使用OffsetDateTime.parse去解析。这里透露一个细节判定为时间格式的工具只负责判定值是时间格式不代表后续能读取到你想要的时间粒度格式定义要与你后面的业务操作保持一致。4.3 性能与线程安全性能方面遍历多个DateTimeFormatter解析同一个字符串本身就是一种轻量级操作。正常情况下一次解析耗时在几十微秒量级一万条数据的判定也就几百毫秒。但有两个优化空间。第一同类字符串连续判定时可以提前按“首字符是数字还是字母”做粗筛避免每一条都从头遍历全部格式。第二把格式列表按匹配概率排序“yyyy-MM-dd”这类最常见的放在前面可以减少平均尝试次数。线程安全方面由于DateTimeFormatter是不可变且线程安全的整个工具类没有任何共享可变状态可以放心地在高并发接口里直接调用。4.4 扩展思路如何支持更多格式这个工具做出来之后可以从几个方向继续扩展。熟悉DateTimeFormatterBuilder的人可以把它换成更灵活的构建器比如通过appendValue(ChronoField.YEAR)、optionalStart等机制支持可选字段。比如需要同时支持“2024-03-08”和“2024-03-08 14:30”两种长度时可以用 optional 机制做成一个 formatter而不是在列表里写两条。再比如增加parseToTemporalAccessor方法让调用方在判定成功后直接拿到解析结果省去二次解析的开销。判断是时间格式和取到里面的时间对象是可以一步完成的很多调用方其实想知道的是“这个字符串是不是时间格式是的话里面是多少”如果每次都判完再解析一次性能就浪费了。最后说一下我在实际封装这个工具时的一个体会工具类最难的地方不是实现解析而是定义“什么算合法”。严格模式解决的是“格式匹配 语义合法”如果业务上确实需要兼容“2024-3-8”这种不规范写法宁可在工具类里新增一个isDateStrict和isDateLenient两个方法也不要降低默认判定的严格程度。判定的东西可以用一个原则来概括默认严格按需宽松叫法明确。这样团队里的其他人接手时不会因为“为什么这个字符串在你这儿过了在他那儿没过”来反复问你。
做数据清洗和接口对接的时间长了你会发现一个特别基础但又绕不开的需求怎么判断一个字符串到底是不是时间格式。用户提交的表单里、合作方导出的文件里、爬虫抓下来的字段里总有人把“2024-01-15”写成“2024/1/15”把“15:30”写成“1530”甚至直接丢一个13位的时间戳过来。今天我把这个常用的Java工具方法完整拆开讲一遍从方案选型到完整实现再到实际踩坑记录一次讲透。1. 工具定位这个字符串判断问题为什么值得单独封装1.1 从实际场景出发谁需要这个工具先说说这个工具到底解决什么问题。我在之前的业务开发里遇到过这么几个场景文件导入模块需要从Excel或CSV里解析大量日期字段但每一行数据格式都不一样有的是“2024-03-08 14:30:00”有的是“2024/03/08”还有的是“2024年3月8日”接口联调时对方文档里写的是标准ISO格式实际传过来的却是“08-Mar-2024”数据库导出排查时某个varchar字段里混着“20240115”这种紧凑格式和“2024-01-15 14:30”这种带空格的格式。这种情况如果每个业务方各写一套判断逻辑代码会很散、很难维护。最合理的做法是沉淀一个独立的工具类统一的入口、统一的格式列表、统一的是否严格解析策略项目里所有涉及时间字符串判定的地方都走这个工具。适合用这个工具的开发者包括写数据清洗和ETL的、做接口对接的、维护导入导出功能的以及任何需要在运行时判断字符串语义的人。1.2 为什么正则表达式救不了你一提到“判断字符串是否是时间格式”很多人第一反应是写正则表达式。比如判断日期就写\d{4}-\d{2}-\d{2}判断时间就写\d{2}:\d{2}:\d{2}。这种方式在两三个固定格式的简单场景下能蒙混过关但只要格式一多就会暴露两个致命问题。第一个问题是正则只能判断“外形”不能判断“语义”。“2024-13-45”完全可以通过\d{4}-\d{2}-\d{2}这个正则但它根本不是一个合法日期同样“2024-02-30”在外形上完美匹配却是个不存在的日期。另一个问题是正则对格式变体的覆盖完全靠人工堆模式每加一种格式就得多写一大段到最后模式串比业务代码还难懂改起来牵一发动全身。真正正确的做法是把判断交给时间解析器。解析器会完整检查年月日时分秒的取值是否合法比如月份在1到12之间、日期在当月天数范围内解析失败就直接判定为非法根本不需要你自己去枚举各种非法组合。1.3 方案选型java.time 的解析能力才是正确答案看番Java技能树的开发者都知道老式SimpleDateFormat已经不太适合新项目了这个问题上我们优先选择java.time包下的DateTimeFormatter和LocalDateTime等类。这里有两个关键理由。首先是线程安全。SimpleDateFormat是线程不安全的多个线程共用一个实例会在内部Calendar状态上打架导致解析出错误结果或者直接抛异常。而DateTimeFormatter是不可变类天然线程安全可以放心地声明成static final常量让整个类共用。其次是严格模式控制。DateTimeFormatter在默认情况下要求字符串严格匹配格式定义年月日数字位数不齐、日期不存在等情况都会抛DateTimeParseException恰好是我们要的“严格校验”效果。当然用java.time不是说完全抛弃正则正则仍然可以作为一个“预筛”环节在解析前快速排除明显不是时间格式的字符串减少不必要的解析尝试。但最终裁决权必须交给解析器。2. 核心细节想清楚「时间格式」到底意味着什么2.1 时间字符串的常见形态动手写代码前先把你可能遇到的所有时间字符串形态盘一遍。我按实际项目中出现的频次做了个分类。第一类是标准日期时间格式也就是yyyy-MM-dd HH:mm:ss及其变体比如2024-03-08 14:30:00。第二类是纯日期格式比如2024-03-08、2024/03/08这类在文件导入中最常见。第三类是紧凑格式包括20240308和20240308143000这种通常从数据库或老旧系统导出。第四类是带时区偏移的 ISO 格式比如2024-03-08T14:30:0008:00这种常见于接口返回体。第五类是时间戳也就是纯数字串可能是10位的秒级时间戳或13位的毫秒级时间戳。在设计工具时我会把日期、时间、日期时间、时间戳分开做判断方法。提供isDate、isTime、isDateTime、isTimestamp等入口这样调用方可以根据字段含义选择最精确的判定而不是笼统地调一个方法。2.2 严格解析与宽松解析的分界线这里有个很容易踩坑的概念解析器有两种模式严格模式和宽松模式。宽松模式下解析器会做一些计算上的“纠正”比如把2024-02-30解析成2024-03-01把2024-13-01解析成下一年的1月1日而不是报错。这显然不是我们想要的行为因为2024-02-30这个字符串本身并不是一个合法的时间格式。DateTimeFormatter默认使用严格解析这对我们是友好的。但要注意通过DateTimeFormatter.ofPattern(yyyy-MM-dd)创建的解析器在严格模式下要求格式定义与字符串一一对应。比如“2024-3-8”这种月份和日期只有一位数字的字符串用yyyy-MM-dd去解析会失败因为模式里的MM代表至少两位数字。如果你想兼容这种写法就得把 pattern 改成yyyy-M-d或者使用DateTimeFormatterBuilder配合parseLenient来放开位数限制。我的建议是工具默认保持严格模式保证判定结果可靠如果某些调用方明确需要容错可以额外提供ALLOW_LOOSE参数或单独的宽松判定方法由调用方自行选择。默认严格是最安全的行为。2.3 特别容易被忽略的格式陷阱YYYY、MM、HH大小写含义写时间格式解析时DateTimeFormatter的 pattern 字母大小写是有严格含义的搞混了会出大问题。这里挑三个最容易翻车的字母说。第一个是yyyy和YYYY的区别。小写y表示“年”大写Y表示“周年”Week-Based-Year。在跨年那一周“2024-12-30”这个日期的周年是2025年。如果解析时用了YYYY-MM-dd返回值会是2025年12月30日业务数据就这么被悄悄改了一年。判断时间格式的工具如果用了YYYY对2024-12-30这种字符串依然会判定为合法但它解析出来的结果已经不对了。第二个是MM和mm的区别。MM是月份mm是分钟。2024-03-08 14:30里的30用mm才正确写成MM会直接报错或者解析出离谱的结果。第三个是HH和hh的区别。HH是24小时制0到23hh是12小时制1到12后面还需要带上a表示上下午。如果你只想支持24小时制格式pattern 里必须用HH。这些细节虽然不影响“判定是否合法”的结果但如果后续要从解析结果里读日期字段、做格式化或比较就会暴露出严重问题。工具类里只使用明确无误的 pattern 字母是职业习惯问题。3. 实操过程一步一步写出可落地的工具类3.1 工具类结构设计接下来把完整实现写出来。这个类我命名为DateParseUtil职责单一只负责“判断一个字符串是否是时间格式”不做格式化、转换、计算等多余的事。类结构上分为四层。常量层存放所有预定义的日期时间 pattern比如yyyy-MM-dd HH:mm:ss、yyyy-MM-dd、yyyy/MM/dd、yyyyMMdd、ISO 时间格式等统一转换为DateTimeFormatter并放入一个不可变列表。判定层提供一系列public static boolean方法内部遍历格式化器列表逐一尝试解析捕获到解析成功且完整消耗整个字符串的情况返回 true。工具层是核心私有方法tryParse它把重复的遍历逻辑收起来。便利层提供isDate、isTime、isDateTime等带业务语义的入口。这种分层的好处是新增一种时间格式时只在常量层追加一条 pattern需要新语义判定时只在入口层增加一个方法。调用方不需要关心内部实现细节。3.2 完整代码实现下面直接上代码。这个类可以直接复制到项目里使用JDK 8 及以上都可以。import java.time.LocalDate; import java.time.LocalDateTime; import java.time.LocalTime; import java.time.format.DateTimeFormatter; import java.time.format.DateTimeParseException; import java.time.temporal.TemporalAccessor; import java.util.ArrayList; import java.util.Arrays; import java.util.List; public class DateParseUtil { private static final ListDateTimeFormatter DATE_FORMATTERS createFormatters( yyyy-MM-dd, yyyy/MM/dd, yyyyMMdd, yyyy.MM.dd, yyyy年MM月dd日 ); private static final ListDateTimeFormatter TIME_FORMATTERS createFormatters( HH:mm:ss, HH:mm, HHmmss ); private static final ListDateTimeFormatter DATE_TIME_FORMATTERS createFormatters( yyyy-MM-dd HH:mm:ss, yyyy-MM-dd HH:mm, yyyy/MM/dd HH:mm:ss, yyyy-MM-ddTHH:mm:ss, yyyy-MM-ddTHH:mm:ssXXX, yyyy-MM-ddTHH:mm:ss.SSSXXX, yyyyMMddHHmmss ); private static ListDateTimeFormatter createFormatters(String... patterns) { ListDateTimeFormatter list new ArrayList(); for (String pattern : patterns) { list.add(DateTimeFormatter.ofPattern(pattern)); } return list; } private DateParseUtil() { // 工具类不允许实例化 } public static boolean isDateTime(String str) { return isType(str, DATE_TIME_FORMATTERS); } public static boolean isDate(String str) { return isType(str, DATE_FORMATTERS); } public static boolean isTime(String str) { return isType(str, TIME_FORMATTERS); } public static boolean isTimestamp(String str) { if (str null || str.isEmpty()) { return false; } if (!str.chars().allMatch(Character::isDigit)) { return false; } try { long value Long.parseLong(str); // 粗略判断10位为秒级时间戳13位为毫秒级时间戳 long lowerBound 8; // 100000000 秒约1973年 long upperBound 13; int digitCount str.length(); if (digitCount 10) { return value lowerBound value 10000000000L; } else if (digitCount 13) { return value 1000000000000L lowerBound * 1000L value 10000000000000L; } return false; } catch (NumberFormatException e) { return false; } } public static boolean isDateTimeOrDate(String str) { return isDateTime(str) || isDate(str); } private static boolean isType(String str, ListDateTimeFormatter formatters) { if (str null || str.trim().isEmpty()) { return false; } String input str.trim(); for (DateTimeFormatter formatter : formatters) { try { TemporalAccessor parsed formatter.parse(input); if (parsed ! null) { return true; } } catch (DateTimeParseException e) { // 未匹配继续尝试下一种格式 } } return false; } public static void main(String[] args) { String[] samples { 2024-03-08, 2024/03/08, 20240308, 2024-03-08 14:30:00, 2024-03-08T14:30:0008:00, 14:30:00, 14:30, 143000, 2023-02-30, 2024-13-01, abcde, 2024-3-8, }; for (String s : samples) { System.out.println(s isDateTimeOrDate(s)); } } }这段代码有几个设计细节值得说。createFormatters方法把字符串列表转换成DateTimeFormatter列表新增格式时只需要增加一行字符串。isType是判定核心先做空值检查和trim()处理再去遍历解析。formatter.parse(input)如果成功返回TemporalAccessor走到这说明字符串整体完整匹配并且语义合法直接认定 true如果抛DateTimeParseException说明这一种格式匹配不上继续尝试下一种。3.3 关键参数与配置说明这里有几个参数和配置可以按业务需要调整。格式列表是整个工具的灵魂。我上面给的是保守基础版项目里如果还有dd-MM-yyyy、MM/dd/yyyy等欧美习惯格式直接往列表里加。还要注意 pattern 里的空格、T、时区偏移量XXX都要和实际数据完全一致。一个容易忽略的点yyyy-MM-dd HH:mm:ss里的单个空格是普通字符解析时字符串里必须有一个空格如果线上数据是两个空格或者全角空格就会判定失败。这种场景建议在isType里对多个空格做归一化处理。时间戳的判定我写的是粗略但实用的逻辑。10位数字覆盖了从1973年到2286年之间的秒级时间戳13位数字覆盖了毫秒级时间戳。如果业务里出现过16位微秒时间戳可以再加一个长度分支。3.4 使用示例与边界测试我们来跑一下main方法里的样例数据。结果应该是2024-03-08→ true2024/03/08→ true20240308→ true2024-03-08 14:30:00→ true2024-03-08T14:30:0008:00→ true14:30:00→ true14:30→ true143000→ true2023-02-30→ false2024-13-01→ falseabcde→ false2024-3-8→ false→ false几个边界结果简单说明一下2023-02-30判 false 是因为2月30日根本不存在2024-13-01判 false 是因为13月不存在2024-3-8判 false 是因为月份的MM要求至少两位数字如果要兼容这种写法得把 pattern 里的MM改成M。这些结果刚好体现了“解析器做最终裁决”的设计思路。4. 常见问题与排查技巧实录4.1 经典坑点速查表把实际开发和维护中遇到的高频问题整理成一张表排查时可以快速对照。问题现象根源解决方案用YYYY-MM-dd解析把跨年日期算到下一年大小写字母含义搞混pattern 统一使用小写yyyy解析异常的程序突然挂掉没有捕获DateTimeParseException判定方法内部必须捕获该异常多线程下日期解析偶尔出错共用非线程安全的SimpleDateFormat改用DateTimeFormatter全角空格导致解析失败数据里混入不可见字符判定前先做replaceAll(\\s, )2024-02-30被判合法用了宽松解析模式或正则预判确保DateTimeFormatter严格模式4.2 实战中遇到的两个典型故障第一个故障发生在某次批量导入任务里。数据源是一张老旧的业务表日期字段以字符串形式存储长度和格式都比较混乱。导入代码最初用的是SimpleDateFormat加宽松模式结果一批 “2024-02-30” 之类的脏数据被强制修正成新日期写入新库事后对账发现和原库相差了十几天。排查半天才发现是解析器在宽松模式下做了日期溢出自动进位。后来换成严格的DateTimeFormatter这类问题就再也没出现过。第二个故障是时区偏移被默认吞掉。某接口返回的字段是2024-03-08T14:30:0008:00判定工具返回了 true但后续转换时想取出LocalDateTime发现结果里竟然没有时区偏移信息。原因是DateTimeFormatter.ofPattern(yyyy-MM-ddTHH:mm:ss)只能解析没有时区的那一部分。如果要保留时区信息必须用带XXX的 pattern或者直接使用OffsetDateTime.parse去解析。这里透露一个细节判定为时间格式的工具只负责判定值是时间格式不代表后续能读取到你想要的时间粒度格式定义要与你后面的业务操作保持一致。4.3 性能与线程安全性能方面遍历多个DateTimeFormatter解析同一个字符串本身就是一种轻量级操作。正常情况下一次解析耗时在几十微秒量级一万条数据的判定也就几百毫秒。但有两个优化空间。第一同类字符串连续判定时可以提前按“首字符是数字还是字母”做粗筛避免每一条都从头遍历全部格式。第二把格式列表按匹配概率排序“yyyy-MM-dd”这类最常见的放在前面可以减少平均尝试次数。线程安全方面由于DateTimeFormatter是不可变且线程安全的整个工具类没有任何共享可变状态可以放心地在高并发接口里直接调用。4.4 扩展思路如何支持更多格式这个工具做出来之后可以从几个方向继续扩展。熟悉DateTimeFormatterBuilder的人可以把它换成更灵活的构建器比如通过appendValue(ChronoField.YEAR)、optionalStart等机制支持可选字段。比如需要同时支持“2024-03-08”和“2024-03-08 14:30”两种长度时可以用 optional 机制做成一个 formatter而不是在列表里写两条。再比如增加parseToTemporalAccessor方法让调用方在判定成功后直接拿到解析结果省去二次解析的开销。判断是时间格式和取到里面的时间对象是可以一步完成的很多调用方其实想知道的是“这个字符串是不是时间格式是的话里面是多少”如果每次都判完再解析一次性能就浪费了。最后说一下我在实际封装这个工具时的一个体会工具类最难的地方不是实现解析而是定义“什么算合法”。严格模式解决的是“格式匹配 语义合法”如果业务上确实需要兼容“2024-3-8”这种不规范写法宁可在工具类里新增一个isDateStrict和isDateLenient两个方法也不要降低默认判定的严格程度。判定的东西可以用一个原则来概括默认严格按需宽松叫法明确。这样团队里的其他人接手时不会因为“为什么这个字符串在你这儿过了在他那儿没过”来反复问你。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
