2020年是一个闰年（Leap Year），闰年是会出故障的。八年前，2012年2月29日，我在Azure的时候我们就出了一个大故障：https://azure.microsoft.com/en-us/blog/summary-of-windows-azure-service-disruption-on-feb-29th-2012/
其实，闰年并不是每四年一次。2000是闰年，但1900年和2100都不是闰年。
1、在一个日期值上加或减时间的代码。尤其是加减1年或1个月的代码2、各种根据数据库查询结果生成的报表和图标，月度和年度统计可能会少算1天3、证书/密码/密钥/缓存 等的过期时间，可能会比预期的早了一天，或者可能设定了一个非法的过期时间4、固定长度的数组。例如，一个长度为365的数组遇到闰年可能就不够了，可能会数组越界。5、UI组件，例如日历、日期选择组件，以及客户端输入校验相关的代码。
2019年12月31日：这是闰年前一年的最后一天。2019年的最后一天加365天，并不是2020年的最后一天，而会是2020年的倒数第二天（即2020年12月30日）。2020年1月1日：闰年的第一天。闰年的第一天加365天，并不是下一年的1月1日，而是今年的12月31日。 2020年1月31日：这一天加28天，并不是下个月（2月）的最后一天。2020年2月1日：这一天加28天，并不是下个月（3月）的第一天。2020年2月28日：这是2月29日的前一天。有问题的代码可能会错误的把这天当成2月的最后一天，试图加1天得到3月1日。但实际上这一天加1天是2月29日。2020年2月29日：这是闰年多出来的一天。如果代码以为2月总是只有28天，那代码可能出现各种问题，例如：
入参校验会认为一个合法输入（2020/2/29）是非法的，用```{ year+1 , month , day }```的方式来加减1年的话会产生一个非法日期。2020年3月1日：2月29日后面的那天。代码如果在3月1日上减28天，会得到2月2日（而不是预期中的2月1日）；减365天的话会得到2019年3月2日（而不是预期中的3月1日）。代码如果不能正确处理一年的第366天，可能也会导致问题。例如，2008年12月31日，第三方软件中的问题导致了所有Microsoft Zune设备无法使用，详情参考：http://www.theguardian.com/technology/blog/2009/jan/01/zune-firmware-mistake代码如果假设1年永远是365天，声明了一个固定大小为365的数组，那在一年的第366天可能会发生数组越界。数组越界如果发生在 C/C++ 语言编写的代码里，可能导致内存溢出攻击漏洞。
https://en.wikipedia.org/wiki/Leap_second不过由于在阿里巴巴经济体大部分同学平时相处的都是应用层代码，处理的都是日月年，最多也就精细到小时和分钟，闰秒对我们的影响相对小很多。闰秒对于GPS等一些对时间的精密度要求比较高的系统会影响比较大。郑子颖，花名南门，现任职蚂蚁金服 国际事业群 质量和技术风险部 资深总监。上海交通大学计算机系硕士毕业后加入微软，2018年加入蚂蚁金服。从事软件开发18年，工作重心主要围绕着测试、质量以及工程效能。目前，我团队正在国内和海外多地招聘测试开发岗位，欢迎海内外专业人士加入我们，职位详情：
https://hire.alibaba-inc.com/i18n/positionDetail.html?positionId=576717![]()
Tips：
# 点下“在看”❤️
# 然后，公众号对话框内发送“我爱我家”，试试手气？😆
# 本期奖品是阿里家书一套。