由程序猿yyyy-MM-dd跨年Bug引发的深思

本文在微信公众号龍行天下之程序人生同步发布，欢迎大家留言讨论。

• 缘起

这几天时有文章在讨论yyyy-MM-dd跨年Bug，大到互联网一线大厂微信赞赏功能，小到进京车辆牌照办理APP，甚至小区门口车牌识别功能也因此Bug导致车辆无法正常进出。

挖其背后深层次原因恐怕与大多“程序猿”习惯的“复制、黏贴”工作状态有关，与测试“攻城狮”边界测试有关系，更甚至与“人人都是产品经理”的产品经理也有很大的关系。如果一个产品仅仅满足于常规情况下正常运行，不考虑特殊情况及异常情况的处理逻辑，想想产品的用户体验满意度能好到哪里去。

• 再论程序员职业

在我们的印象中，似乎只有舞蹈演员、T台模特、空姐这类吃青春饭的职业。现在程序员这个职业，也被人贴上了“青春”的标签，甚至流传着程序员如果35岁不转行，就是在等死这样危言耸听的言论，为何平均工资上万的程序员们，会有这样的焦虑呢？

任正非曾这样回应华为裁员：“华为是没有钱的，大家不奋斗就垮了，不可能为不奋斗支付什么，30多岁年轻力壮，不努力，光想躺在床上数钱，可能吗？”

35岁危机，并不是程序员的专属，事实上绝大部分岗位都有这样窘境。有人选择了继续深耕技术往技术专家发展，而有人则向偏管理方向转岗了，不同人选择不同而已。

扪心自问，转岗又能做什么呢？自身优势在哪里？别人为什么选择我？

仔细想想一个企业裁员是不是完全是因为企业的原因，我们自身能否做的更好，这个值得我们大家深思。

好了，说多了该被骂了。

• 回归到主题

网上大家都是在讨论yyyy-MM-dd的Bug，很少人有说HH:mm:ss与hh:mm:ss的区别。在问题还没有发生时，我们是否应该去自主检测一下是否有问题风险存在呢。

我们试着用Java语言写个日期格式化工具，打印结果看看有什么不同：

 

从打印结果看发现区别还是很大的，因此对于时间精度要求严格的业务场景需要从时间数据落库再到数据展现给用户，都需要严格检查其是否合理正确。

另外请大家可以试着改变HH:mm:ss中mm与ss的大小写看看有什么变化，真正理解不同日期格式化所适用的场景，以便在实际场景中能合理应用。

 

• 附MySql与Oracle日期时间格式

   

  MySql

  %Y-%m-%d %H:%i:%s    24小时制

  %Y-%m-%d %h:%i:%s    12小时制

  Oracle

  yyyy-MM-dd HH24:mi:ss    24小时制 

  yyyy-MM-dd HH:mi:ss        12小时制