再来推广一下这个 Java 工具库，绝对能提高你的工作效率，欢迎 V 友一起讨论

还是那句打击人的老话,工具或者框架最看重的不是运行效率而是有人更新维护
运行效率开发效率可以更新优化提升,所以这也是为什么都选择 apache google srping 的原因

哈哈，你可以看看我的 commit，一直在维护这个项目，另外还有好几个开发者也加入到其中来

看到那堆依赖就放弃了。。。

有点尴尬，说轻便吧依赖不少功能很杂，说大而全吧好像功能也没很丰富…

和 hutool 比，优势在哪里

DateUtil.stringToDate("20200101") == null
DateUtil.stringToDate("2020-01-01 10:20") == null
DateUtil.stringToDate("2020-01-01 10:20:30.012") == null

不过 java 的 SimpeDateFormat.parse 真是难用，规矩真他娘多，少一个位就 throw，对于上面这些很规律的时间字符串，我先自己解析一遍，在拼成 SimpleDateFormat.parse 能接受的格式，看下图

DateUtil 缺失必要过程：
public static Date stringToDate(String dateStr, TimeZone zone) //stringToDate(String)应当算仅仅调用这个方法，只是提供了默认时区而已

----------


这样就可以解析下面这坨，支持的范围更广很多：
202001011020
2020-01-01
2020-01-01 10:20
2020/01/01 10:20:30
2020/01/01 10:20:30.012
2020 年 1 月 1 日 10:20

@xiangyuecn 时代变了…现在都用 DateTimeFormatter
Date 和它配套的类都是时代的产物，无脑抄袭别的语言的产物，garbage in garbage out 的产物

@ChanKc #7 java 的时间处理混乱的一逼，学不动。在没有涉及到时间计算上，我还是 long 类型的时间用的多 跨语言交互也算方便

@xiangyuecn Java8 之后的 LocalDateTime 或者 ZonedDateTime 都很好用，加减比较间隔都有现成 API

@xiangyuecn 计算？ LocalDateTime.now(). plusHours(1L) 要时区你有 ZonedDateTime，方法几乎一样

老板，你的字母拼错啦，是 wrapper 不是 warpper 。而且建议把 dependency 都变成 optional 的，不然一下子出来一大片各种不同功能的依赖，或者抽成子 module （不过每一个 module 就一个 util 类显得有点干瘪了）


https://i.loli.net/2020/06/29/MnRSEV1uDZFOLeI.png

说句更打击人的
希望我的同事不要看到这个，万一引入了出了个依赖的 cve 还得花时间去改去上线

Hutool 不香嘛

@qwerthhusn 哈哈，拼写我后面会注意，拆成 module 打包，我也计划这么做，减少单个 moudle 的依赖，我看 hutool 也是这么做的

提供一堆代码，让大家 CV 感觉效果要好于一个依赖……

加油; 模仿着一步步来; 折腾起来

@xiangyuecn #6 LocalDateTime