我有以下代码片段:
final Date d = format.parse(value);LOGGER.deBUG("Compare:\noriginal: {}, Format: {}, Result: {}", value, format.topattern(), d);return d;
value是来自Json的String值,
format是java.text.SimpleDateFormat,
d是从值解析的Date
有时它工作正常,但有时会返回奇怪的日期.
logcat示例:
D/App: 20:14:47.309 com.example.backend.BackendHelper - Compare: Original: 2016-09-16 13:45:00.000+0200, Format: yyyy-MM-dd HH:mm:ss.SSSZ, Result: Fri Jan 01 05:00:00 GMT+07:00 2016D/App: 20:14:47.309 com.example.backend.BackendHelper - Compare: Original: 2016-09-16 13:20:00.000+0200, Format: yyyy-MM-dd HH:mm:ss.SSSZ, Result: Fri Jan 01 18:20:00 GMT+07:00 2016D/App: 20:14:47.338 com.example.backend.BackendHelper - Compare: Original: 2016-09-16 15:20:00.000+0200, Format: yyyy-MM-dd HH:mm:ss.SSSZ, Result: Thu Jan 01 05:00:00 GMT+07:00 1970
如您所见,它返回不正确的日期(错误的年份或/和月份或/和小时),这些字符串具有完全相同的格式,并且仅按小时和分钟相互不同.
问题是:为什么?
解决方法:
您的格式模式是正确的.而且这里的区域设置不相关.
好吧,您还在问题中提供了输入,以便我们调查是否存在任何不可打印的字符.没有(和JsON不产生这样的废话 – 非常不可能).
因此,对于观察到的不可预测行为的解释是缺乏线程安全性.不幸的是,SimpleDateFormat不是线程安全的(并且还有许多其他缺点).因此,只将SimpleDateFormat的一个实例存储为静态类字段确实很危险.
如何规避SimpleDateFormat的这个限制?
>将调用同步到parse() – 方法(导致性能损失)
>将SimpleDateFormat-object存储到ThreadLocal中(更好)
>使用FastDateFormat(性能可与ThreadLocale解决方案相媲美,前缀“Fast”现在有点过时了)
>使用ThreetenABP-library(围绕Java-8中新的时间库包java.time的后端的AndroID改编),提供一个不可变的解析器),例如:OffsetDateTime.parse(input,DateTimeFormatter.ofPattern(“yyyy-”) MM-dd HH:mm:ss.SSSZ“))
>使用Joda-Time-Android(比ThreetenABP更快的解析,也是不可变的),例如:DateTimeFormat.forPattern(“yyyy-MM-dd HH:mm:ss.SSSZ”).parseDateTime(input)
>或者试试我的库Time4A(恕我直言最快的解决方案,也是不可变的),例如:ChronoFormatter.ofMomentPattern(“yyyy-MM-dd HH:mm:ss.SSSZ”,PatternType.CLDR,Locale.ROOT,ZonalOffset.UTC ).parse(输入)
选择不可变的格式化程序/解析器无疑是在多线程环境中使用的最佳和最现代的方法.对于AndroID,Apache Commons和ThreetenABP库比Joda-Time或Time4A更快的替代品更紧凑.您必须自己评估哪些对您来说更重要,无论是大小还是性能(或者您需要的其他功能).
总结以上是内存溢出为你收集整理的java – android – SimpleDateFormat以奇怪的方式解析数据.错误的月份或/和年份全部内容,希望文章能够帮你解决java – android – SimpleDateFormat以奇怪的方式解析数据.错误的月份或/和年份所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)