Java 使用SimpleDataFormat类分析日期

我知道这是一个众所周知的简单的解决方案，我将在这里描述这个问题。我试图解析以下日期格式，但只有在传递正确的格式来解析该字符串的情况下才能得到解析异常

try{
  String mDateFormat = "Tue Nov 03 13:46:28 GST 2015";
  SimpleDateFormat mFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy");
  Date mFormattedDate = mFormat.parse(mDateFormat);

  }catch(ParseException e){
     e.printStackTrace();
}

此字符串包含的时区仅引发崩溃。如果我删除它，它就能够正确地解析它。时区格式有点问题，但我也尝试了这个链接所声明的标准：

有人告诉我这里怎么了吗

---

谢谢，

如果您使用的是英语日期，请将代码更改为

SimpleDateFormat parserSDF = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzzz yyyy", Locale.ENGLISH);

---

从我到目前为止所做的所有实验来看，您看到问题所在的Android DateFormat解析器实现似乎不理解GST区域。最简单的解决方案是显式使用格式化程序，将GST替换为GMT+4，如下所示：

String mDateFormat = "Tue Nov 03 13:46:28 GMT+4 2015";

有了这个日期字符串，Android似乎返回了与桌面等价物相同的转换

注意（从格式化程序中删除时区将不是一个正确的解决方案，因为转换将不准确。由于您是从Twitter API获取此日期，您可能需要在Android上格式化之前过滤不可接受的字符串，您可以使用：

mDateFormat.replace("GST", "GMT+4") 

---

将日期格式应用于数据之前。

我所做的简单解决方案：

1） 将时区作为字符串与以下格式分开，并替换为“”：

2） 获取默认时区并在应用SimpleDataFormat时设置相同的时区

final String TWITTER = "EEE MMM dd HH:mm:ss yyyy";
SimpleDateFormat mSf = new SimpleDateFormat(TWITTER, Locale.ENGLISH);
mSf.setTimeZone(TimeZone.getDefault());
Date mNewDate = sf.parse(mActualDate);

---

3） 获取具有相同时区的更新日期。无需使用GMT转换。

对于标准时区，您的意思是将“GST”替换为“GMT”，但仍然不起作用？嘿，对我来说，上面的代码工作得很好。@Nanoc:不，它仍然不起作用@我可以知道你在测试哪个版本的android吗？它在哪个特定的设备上工作？看起来有点像设备相关的问题。这个问题仍然给了他在Android上的例外@Jai的原始代码正确地运行在桌面上。以前在我的代码中出现相同的异常时，它对我有效。但现在它抛出异常。无线索的！！嗨，谢谢你的回答。那么你是说像PST，IST这样的每个timzone。GST无论我会得到什么，我都需要用“GMT+4”来代替？在不同时区的情况下是否准确？在这种情况下，我需要检查每个时区来替换它，对吗？因为如果用户使用来自不同国家的应用程序，此GST将不固定！不。PST是GMT-8，IST是GMT+5:30。我的意思是，目前Android似乎不承认GST。它甚至都不承认它是一个种族主义者。因此，您还需要执行以下操作：mDateFormat.replace（“IST”、“GMT+5:30”）当您收到任何未识别的时区时，您可能需要将其替换为等效的GMT+/-数字。您可以编写一个小的hello world应用程序，找出所有可能的时区中哪些不被Android识别（PST被识别），然后为它们编写一个字符串替换代码。您可以从timeanddate.com/time/zones获得GMT vs other timzeones列表和GMT offset注意，该网站列出了与UTC相比的时间偏移。但它们也可以应用于GMT，因为UTC和GMT之间没有时差。错误的原因是在尝试转换之前删除了原始时区。如果您将在桌面上运行的原始代码的输出与在Android上运行的新代码的输出进行比较，则此新代码会给出错误的结果。以下是样本结果：试验日期：“2015年11月3日星期二13:46:28”；桌面上问题的原始代码将其转换为：2015年11月3日星期二04:46:28东部标准时间。您的新代码将其转换为：星期二11月03日13:46:28 EST 201。请注意时间4与13之间的差异。如果代码正确，则结果应匹配。下面给出一个类比，说明为什么在日期转换之前保留原始时区很重要。假设您需要将货币从1美元转换为日元。使用新方法可以删除$（类似于货币区），然后插入区域设置货币。因此，按照你的方法，$1=1日元是不正确的。基本上，通过删除美元，您将问题从“1美元兑换成日元是多少”修改为“1日元兑换成日元是多少”，这给出了有缺陷的答案results@NileshPawar：Dude，I'，删除原始时区，但添加相同的时区，如果您愿意使用我使用的setTimeZone方法进行检查的话。@NileshPawar:您的桌面可能有最短的时间。这就是为什么它正在转换为EST。但你检查的验证是错误的。因为GST是我的硬编码，因为我在GST时区。如果您将从twitter api读取任何数据，您将在resutl而不是GST中获得EST，因此我的流程将首先删除它，然后它将再次添加您桌面的EST时区。因此，请理解流程：）@NileshPawar：对于您的测试用例，您应该使用2015年11月3日13:46:28 EST而不是GST。然后你会得到准确的结果。这就是我们应该尝试的实际用例。当然，如果您使用GST进行输入并添加EST（作为系统的默认时区），则它将不起作用：）

final String TWITTER = "EEE MMM dd HH:mm:ss yyyy";
SimpleDateFormat mSf = new SimpleDateFormat(TWITTER, Locale.ENGLISH);
mSf.setTimeZone(TimeZone.getDefault());
Date mNewDate = sf.parse(mActualDate);