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。