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。

posted @ 2019-05-23 16:54 河岸飞流 阅读(...) 评论(...) 编辑 收藏

那片笑声让我想起我的那些花儿
在我生命每个角落静静为我开着
我曾以为我会永远守在她身旁
今天我们已经离去在人海茫茫
她们都老了吧 她们在哪里呀
幸运的是我曾陪她们开放