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。

巴特西

mysql毫秒数引发的问题

最新文章

热门文章