【发布时间】:2018-02-08 09:39:23
【问题描述】:
我在解析String 并格式化生成的Date 时遇到SimpleDateFormat 更改datetimestamp 外观的问题。
下面的代码 sn-p 演示了这个问题。注意:我知道用相同的SimpleDateFormat 解析并格式化相同的日期似乎是徒劳的,但这是一个人为的例子,只是为了演示原理:
DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
String dateStringToConvert = "2016-03-12T22:00:00.000-00:00";
try {
Date date = dateFormat.parse(dateStringToConvert);
String convertedDateString = dateFormat.format(date);
System.out.println("Wanted : " + dateStringToConvert);
System.out.println("Actual : " + convertedDateString);
} catch (ParseException e) {
e.printStackTrace();
}
这个的输出如下:
通缉:2016-03-12T22:00:00.000-00:00
实际:2016-03-12T22:00:00.000Z
由于此日期将用于自动化测试以填写表格,重要的是datetimestamp 的格式在被SimpleDateFormat 解析和格式化后保持完全相同,所以我不不希望它删除-00:00 并添加Z。
这似乎是一个非常简单的问题,但我找不到任何明显的答案。
【问题讨论】:
-
无法保存文本是表示为“+00:00”、“-00:00”还是“Z”。这不是解析值的一部分。如果要保持相同的文本表示,只需保留字符串。还值得注意的是,“-00:00”实际上与 RFC 3339 中的“+00:00”有非常不同的含义。
-
感谢乔恩的评论。我上面以字符串开头的示例可能会混淆我的要求。表达这个问题的一个更简单的方法就是:如何确保 SimpleDateFormt.parse 将返回格式为 2016-03-12T22:00:00.000-00:00 而不是 2016-03-12T22:00:00.000 的字符串Z?从您的评论来看,也许答案是您根本无法做到这一点?
-
如果 any 格式(硬编码除外)返回 -00:00,我会感到惊讶(和担心),因为它具有奇怪的含义。 +00:00(“这与 UTC 之间没有区别”)是否可以接受,或者您的 intention 是否使用 -00:00(“本地时间,我们不知道偏移量” ) 意义?如果是这样,
Date很不幸,因为它代表了一个瞬间...... -
SimpleDateFormat早已过时并且出了名的麻烦。它可能无法解决您的问题,但我仍然建议您改用java.time, the modern Java date and time API,。 -
答案一清二楚:你不能使用
parse方法得到一个看起来像的String任何东西,因为parse方法返回Date,而不是String。
标签: java datetime simpledateformat datetime-format datetime-parsing