【发布时间】:2019-11-08 03:00:33
【问题描述】:
我有这种情况,我正在阅读大约 130K 记录,其中包含存储为字符串字段的日期。有些记录包含空格(null),有些包含这样的字符串:'dd-MMM-yy',有些包含这个'dd/MM/yyyy'。
我写了一个这样的方法:
public Date parsedate(String date){
if(date !== null){
try{
1. create a SimpleDateFormat object using 'dd-MMM-yy' as the pattern
2. parse the date
3. return the parsed date
}catch(ParseException e){
try{
1. create a SimpleDateFormat object using 'dd/MM/yyy' as the pattern
2. parse the date
3. return parsed date
}catch(ParseException e){
return null
}
}
}else{
return null
}
}
所以您可能已经发现了问题所在。 我正在使用 try .. catch 作为我的逻辑的一部分。更好的是我可以事先确定字符串实际上包含某种格式的可解析日期,然后尝试解析它。
那么,是否有一些 API 或库可以帮助解决这个问题?我不介意编写几个不同的 Parse 类来处理不同的格式,然后创建一个工厂来选择正确的6,但是,我如何确定哪一个?
谢谢。
【问题讨论】:
-
如果您决定保留您的解决方案,请仅创建 2 个 SimpleDateFormat 实例并将它们作为常量存储在您的类中,而不是创建 130K 次。
-
如果您将它们存储为常量,请绝对确保它们不会同时从多个线程中使用!我早些时候遇到了问题,并贡献了一个 FindBugs 检测器,它可以找到静态的 DateFormats 和 Calendars。它们被记录为非线程安全的,但很容易错过。见dschneller.blogspot.com/2007/04/…、dschneller.blogspot.com/2007/04/…和dschneller.blogspot.com/2007/05/…
-
@van:不要那样做。 SimpleDateFormat 不是线程安全的,所以如果你在多个线程中使用这个类,事情就会在你的脸上爆炸。
-
我认为我会听取大家的建议并继续使用 try ..catch,因为这确实是一个一次性应用程序,所以我不会在生产环境中运行它。但我会让函数式 Java 成为长期解决方案。我觉得很干净。谢谢。
-
由于线程安全问题,经过漫长的调试过程,我建议使用JODA。它是完全线程安全的,因为所有格式化程序和日期时间都是不可变的。