发生错误java.text.ParseException:无法解析的日期:(偏移量为0)，即使简单日期格式和字符串值相同 [英] Getting error java.text.ParseException: Unparseable date: (at offset 0) even if the Simple date format and string value are identical
问题描述
即使要检查的格式和字符串值相同，我也总是会遇到解析异常. 这是代码:
I'm always getting the parse exception even if the format to check and the string value are same. Here is the code:
String format = "EEE MMM dd HH:mm:ss z yyyy";
String value = "Mon Sep 18 10:30:06 MST 2017";
public static boolean isValidFormat(String format, String value) {
Date date = null;
try {
SimpleDateFormat sdf = new SimpleDateFormat(format);
date = sdf.parse(value); // here it breaks
if (!value.equals(sdf.format(date))) {
date = null;
}
} catch (ParseException ex) {
ex.printStackTrace(); //java.text.ParseException: Unparseable date:
"Mon Sep 18 10:30:06 MST 2017" (at offset 0)
}
return date != null;
}
推荐答案
它表示您的日期时间字符串在索引0处不可解析.索引0表示Mon，因此三字母时区缩写不是第一个嫌疑犯.语言环境是. 星期一"是英语的星期一的缩写，但不是很多其他语言的缩写.因此，如果您的设备设置了非英语的设置(也许最近才更改过)，这将完全说明您的观察.
It says that your date-time string is unparseable at index 0. Index 0 is where it says Mon, so the three letter time zone abbreviation is not the first suspect. The locale is. "Mon" works as abbreviation for Monday in English, but not in very many other languages. So if your device has a non-English language setting — maybe it has even been changed recently — this will fully explain your observation.
近视解决方案是
SimpleDateFormat sdf = new SimpleDateFormat(format, Locale.ROOT);
我使用Locale.ROOT表示不应执行任何语言特定的处理.如果您的字符串是英语，因为英语通常是全球计算中使用的语言，那么我认为这种选择是合适的.另一方面，如果它是英语的，因为它来自说英语的语言环境，那么该语言环境将是正确的选择.
I use Locale.ROOT to mean that no language specific processing should be done. If your string is in English because English is generally the language used in computing around the globe, I would consider this choice appropriate. If on the other hand it is in English because it comes from an English speaking locale, that locale will be the right one to use.
进行此更改后，在我的计算机上，您的代码将日期格式设置为Mon Sep 18 11:30:06 MDT 2017，如您所见，该日期与我们开始时使用的值不同，因此您的方法返回false.我的JVM将MST理解为山区标准时间"，然后假设是9月的夏令时(DST)，并相应地格式化了字符串.
With this change, on my computer your code formats your date into Mon Sep 18 11:30:06 MDT 2017, which, as you can see is not the same as the value we started out from, so your method returns false. My JVM understood MST as Mountain Standard Time, and then assumed summer time (DST) in September and formatted the string accordingly.
也就是说，Date和SimpleDateFormat是早已过时的类.您应该考虑一下以摆脱它们，而使用现代的Java日期和时间API.在Android上，您可以在ThreeTenABP中获得它，请参见此问题:如何在Android项目.现在您可以这样做:
That said, Date and SimpleDateFormat are long outdated classes. You should give it a thought to get rid of them and use the modern Java date and time API instead. On Android you get it in the ThreeTenABP, see this question: How to use ThreeTenABP in Android Project. Now you may do:
DateTimeFormatter dtf = DateTimeFormatter.ofPattern(format, Locale.ROOT);
try {
return ZonedDateTime.parse(value, dtf).format(dtf).equals(value);
} catch (DateTimeParseException dtpe) {
dtpe.printStackTrace();
return false;
}
这与上面的行为相同.
您应尽可能避免使用三个字母和四个字母的时区缩写.它们不是标准化的并且通常是模棱两可的.例如，MST可能表示马来西亚标准时间或山区标准时间.后者甚至不是一个完整的时区，因为MDT在一年中的大部分时间里都使用，这引起了我如上所述的麻烦.
You should avoid the three and four letter time zone abbreviations where you can. They are not standardized and generally ambiguous. MST, for example, may mean Malaysia Standard Time or Mountain Standard Time. The latter isn’t even a full time zone, since MDT is used for the greater part of the year, which caused the trouble I observed as I said above.
相反，请查看是否可以获得ISO 8601格式的字符串，例如2017-09-18T10:30:06+08:00.第二好，得到明确的东西.一种方法是包括相对于UTC的偏移量，而不是时区ID(或两者都包括).
Instead, see if you can get a string in ISO 8601 format, like 2017-09-18T10:30:06+08:00. Second best, just get something unambiguous. One way is to include an offset from UTC rather than a time zone ID (or both).
这篇关于发生错误java.text.ParseException:无法解析的日期:(偏移量为0)，即使简单日期格式和字符串值相同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
