JSON传输Long型时间戳丢失时分信息的问题排查

这问题我之前帮同事排查过类似的，咱们一步步拆解清楚：

为什么会出现时分秒丢失的情况？ #

最可能的原因集中在服务端JSON生成逻辑或者客户端解析的细微差异上，结合你迁移到JBoss才出现问题的背景，先看这几个核心点：

1. 服务端生成的JSON内容本身就不对
   虽然你代码里是直接输出myCreationFunctionForTheJSONString()的结果，但WebLogic和JBoss的运行环境差异可能导致生成的时间戳出错：

   • 比如你的JSON生成逻辑依赖了容器的默认时区，WebLogic和JBoss的默认时区配置不同，导致时间戳计算时直接截断了时分秒；
   • 序列化JSON用的库（比如Jackson、Gson）在两个容器里的版本或配置不一样，比如是否开启了自动将日期转为当天0点时间戳的规则。

2. 客户端AJAX解析的隐性转换
   你提到直接在控制台赋值JSON变量时没问题，但$.getJSON获取后就出问题——这说明通过AJAX请求时，可能触发了额外的解析逻辑：

   • 虽然$.getJSON本质是调用JSON.parse，但如果响应头有细微差异（比如JBoss返回的Content-Type带了额外参数），可能让jQuery或浏览器的解析器自动把13位数值转换成了Date对象，且转换过程中出现了错误；
   • 也有可能客户端代码里有全局的AJAX转换器，悄悄修改了日期字段的解析规则。

具体调试方向 #

按优先级来：

• 第一步：先确认服务端输出的JSON是否一致
  这是最关键的一步，直接排除是服务端还是客户端的问题：

  1. 在服务端代码里加日志，打印jsonTests的完整内容：

     System.out.println("Generated JSON Content: " + jsonTests);
     

  2. 或者直接在浏览器里访问该接口，用Chrome开发者工具的「Network」面板查看原始响应内容，对比WebLogic和JBoss返回的datetime字段数值是否完全相同。如果数值不一样，问题肯定在服务端的JSON生成逻辑。

• 第二步：排查服务端JSON生成逻辑
  如果确认服务端输出的时间戳有误，重点检查：

  • 生成时间戳的代码是否依赖默认时区？比如有没有明确指定时区（比如TimeZone.getTimeZone("GMT+01")），还是直接用了容器的默认值；
  • 所用的JSON序列化库配置：比如Jackson是否开启了WRITE_DATES_AS_TIMESTAMPS，有没有自定义的日期序列化器把时分秒截断了；
  • 对比两个容器里JSON库的版本，会不会是版本差异导致的序列化行为变化。

• 第三步：验证客户端解析过程
  如果服务端输出的JSON完全正确，那问题在客户端：
  把$.getJSON换成原生$.ajax，手动获取原始文本并解析，看结果是否正常：

  $.ajax({
    url: "你的接口地址",
    dataType: "text",
    success: function(rawData) {
      console.log("原始JSON文本:", rawData);
      var parsedData = JSON.parse(rawData);
      console.log("解析后的datetime:", parsedData.testruns[0].datetime);
      // 和直接赋值的结果对比
      var testData = {"testruns":[{"datetime":1515413387000}]};
      console.log("直接赋值的datetime:", testData.testruns[0].datetime);
    }
  });
  

  这样能排除$.getJSON自动解析时的隐性转换问题。另外检查客户端有没有全局的AJAX转换器或自定义JSON解析逻辑。

• 第四步：对比响应头差异
  在Chrome开发者工具里对比WebLogic和JBoss返回的响应头，重点看Content-Type、Cache-Control这些字段，比如JBoss是否多了charset=UTF-8之类的参数，会不会触发了不同的解析规则。

内容的提问来源于stack exchange，提问作者jumps4fun