【问题标题】:Parsing custom time format with SimpleDateFormat使用 SimpleDateFormat 解析自定义时间格式
【发布时间】:2012-12-07 16:58:31
【问题描述】:

我无法解析从 API 返回的日期格式并且我从未见过(我相信是自定义格式)。日期示例:

/Date(1353447000000+0000)/

当我第一次遇到这种格式时,我很快就发现它是以毫秒为单位的时间,带有时区偏移。不过,我无法使用 SimpleDateFormat 提取此日期。这是我的第一次尝试:

String weirdDate = "/Date(1353447000000+0000)/";

SimpleDateFormat sdf = new SimpleDateFormat("'/Date('SSSSSSSSSSSSSZ')/'");

Date d1 = sdf.parse(weirdDate);
System.out.println(d1.toString());
System.out.println(d1.getTime());
System.out.println();

Date d2 = new Date(Long.parseLong("1353447000000"));
System.out.println(d2.toString());
System.out.println(d2.getTime());

然后输出:

Tue Jan 06 22:51:41 EST 1970
532301760

Tue Nov 20 16:30:00 EST 2012
1353447000000

日期(和解析的毫秒数)甚至还没有接近,我无法弄清楚原因。经过一些故障排除后,我发现我尝试使用 SDF 的方式明显存在缺陷。示例:

String weirdDate = "1353447000000";

SimpleDateFormat sdf = new SimpleDateFormat("S");

Date d1 = sdf.parse(weirdDate);
System.out.println(d1.toString());
System.out.println(d1.getTime());

然后输出:

Wed Jan 07 03:51:41 EST 1970
550301760

我不能说我曾经尝试过以这种方式使用 SDF 来解析以毫秒为单位的时间,因为我通常会使用 Long.parseLong() 并将其直接传递给 new Date(long)(实际上我的解决方案have in place right now 只是一个正则表达式和一个 long 解析)。我正在寻找一种更简洁的解决方案,我可以轻松地以毫秒为单位提取时区时间,并快速解析为日期,而无需繁琐的手动处理。任何人都有任何想法或可以发现我上面的逻辑中的错误?非常感谢您的帮助。

【问题讨论】:

    标签: java date simpledateformat


    【解决方案1】:

    取字符串中的毫秒值:

    /Date(1353447000000+0000)/
    

    并将该值作为 long 传递给 Date 构造函数:

    Date date = new Date(1353447000000);
    

    并使用 SimpleDateFormat 格式化日期对象。

    【讨论】:

    • 是的,我认为 SDF 不知道如何处理以大量小单位表示的日期时间,无论是自纪元以来的毫秒数还是自纪元以来的天数。一个明显的迹象,即使在设计层面,也就是日月和日使用两种不同的模式字母。
    • 是的,这就是我现在的解决方案。我有一个正则表达式,它可以提取该值并按照您上面的解释进行操作。我也将不得不解析时区偏移量,就像我想象的那样。我只是希望避免这种手动处理......
    【解决方案2】:

    尽管这几乎就是您现在正在做的事情,但我认为手动方法没有太大问题 - 除了您必须去那里很遗憾!

    我不相信您可以仅使用 SDF 来做到这一点。 这会给你一个合理“优雅”的约会:

    Date date = new Date(Long.parseLong(weirdDate.split("[^\\d]")[6]));
    

    我确定您已经考虑过了,但是您是否与 API 的生产者谈过,了解他们为什么以如此奇怪的格式输出此值?如果接口不公开和/或不普及,他们可能会考虑将其更改为更传统的东西。

    【讨论】:

    • 如你所说,我考虑过询问 API 的所有者为什么他们使用这种奇怪的格式,但我没有。这是一家相当大的公司,我认为它有许多客户针对他们的 API 进行编码,因此更改对他们来说可能是不可行的(尽管这提出了以前是否提出过这种担忧的问题......)跨度>
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-10-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多