问题引出:在mysql环境在,发现日志的具体记录时间不对头。
补充:最终发现该问题可能不是mysql的特定问题,只是说在oracle上确实没发现这个BUG……
这批时间不对,我是先点击编辑,然后编辑2、3、4、5、6,最后点击审核。
除了顺序先后不一致,还存在时间点跟当前系统时间对不上的问题。
追踪日志入库时的情况:
INSERT INTO T_LOG(N_ID,C_UPDATE_TIME,C_STATE,C_USER)
VALUES(?,${getDateTimeMill(yyyymmdd hh24miss.ff3)}$,?,?)
发现这个C_UPDATE_TIME使用的日期格式为yyyymmdd hh24miss.ff3
select now();
此时在dbeaver上执行select now();发现此时此刻时间是对得上当前系统时间的。
查看数据库中的时间,发现这个时间其实是正确的!
抽取代码中的核心点打印,发现在格式转化这个存在问题
logger.info("数据库查询:"+
resultSet.getString("C_UPDATE_TIME")+",java转化:"+
sdf2.format(sdf.parse(resultSet.getString("C_UPDATE_TIME"))));
经过java转化之后的日期大小不对!
细化一下,便是:
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd HHmmss.SSS");
SimpleDateFormat sdf2 = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
直接就是在sdf.parse(resultSet.getString(“C_UPDATE_TIME”))处出现了问题。
这个过程中,我尝试过对sdf的yyyyMMdd HHmmss.SSS中的毫秒SSS进行调试,S从1-6个进行尝试,发现转化出来的时间依旧不准确且发现不了其中的规律性。
最终在这个格式转化导致时间不准确的问题上,没能找到正面的解决方案。于是我直接将数据库中这个时间的字符串直接进行格式处理,因为它就是最原始最准确的!
截掉毫秒,“20230517 234438”处理成“2023-05-17 23:44:38”进行展示。