mysql毫秒数引发的问题

起因：最近同事在做定时打卡的东西，遇到一个诡异的问题，端只是传了一个开始时间跟打卡周期，剩下的打卡时间都是由服务端自己生成的，显示的截止时间有的变成23:59:59. 有时候又变成了 00:00:00，没有找到原因，让帮忙找一下原因，之前没有遇到过这种情况，一时来了兴趣。
探究：
通过编写单元测试，过程并没有出错，入库的时候时间确实是23:59:59,入库之后就变了，相关测试代码如下

    @Autowired
	private JdbcTemplate jdbc;

	@Test
	public void timeTest(){
        Date dateInDay = getDateInDay(new Date(), 23, 59, 59);
        jdbc.update("INSERT INTO test(create_time) VALUES(?)", new Object[] {dateInDay});
    }

    /**
     * 获取某个日期的时刻点，如2017-02-01的18:00:00
     * @param date 开始日期
     * @param hour  时
     * @param minute 分
     * @param second 秒
     * @return
     */
    public static Date getDateInDay(Date date, int hour, int minute, int second){
        Calendar c = Calendar.getInstance();
        c.setTime(date);
        c.set(Calendar.HOUR_OF_DAY, hour);
        c.set(Calendar.MINUTE, minute);
        c.set(Calendar.SECOND, second);
        return c.getTime();
    }

数据库结果：

1	2019-05-23 23:59:59
2	2019-05-24 00:00:00
3	2019-05-24 00:00:00
4	2019-05-24 00:00:00
5	2019-05-23 23:59:59

但是在开发库没有出现这种现象，部署到测试环境就出现这种现象了,其中开发库mysql5.6版本，测试库使用的5.7版本。初步推断是由于数据库版本不一样，对时间处理的不一样导致的，但是具体细节是什么，最终决定去翻阅一下mysql官方的说明文档，终于找到了答案。

从这篇Fractional Seconds in Time Values中我们看到5.6.4之前的版本中是不保存毫秒数的，那么高版本中是如何处理的？

从这篇Conversion Between Date and Time Types中我们看到毫秒数在低于500的时候会舍弃掉，大于等于500会进位，类似四舍五入,既然找到问题的本质原因，那么解决起来也比较方便了，只需要设置一下日期的毫秒数就能得到有效解决，修改如下：

public static Date getDateInDay(Date date, int hour, int minute, int second){
        Calendar c = Calendar.getInstance();
        c.setTime(date);
        c.set(Calendar.HOUR_OF_DAY, hour);
        c.set(Calendar.MINUTE, minute);
        c.set(Calendar.SECOND, second);
        //设置毫秒数，避免产生进位
        c.set(Calendar.MILLISECOND,0);
        return c.getTime();
    }

总结：从这个小问题中，个人最大的感受就是官方api的重要性，对于开发用到的工具、技术要多多关注官方refrence,和release note，看看新加了哪些新特性，优化了哪些内容，修复了哪些bug。