1

由于 BlackBerry 上日期解析的限制，我正在尝试推出自己的解析/解析方法，但不知何故，我似乎在某个地方遇到了一个小时的差异。

我这样做：

long nowLong = System.currentTimeMillis();
String nowString = DateParser.longToString(nowLong);
Date nowDateFromString = DateParser.stringToDate(nowString);
Date nowDateFromLong = DateParser.longToDate(nowLong);

当按顺序输出时，它会在控制台中生成：

[139.46] 1369132556831
[139.46] 21 May 2013 11:35:56 Europe/Dublin
[139.46] Tue May 21 12:35:56 Europe/Dublin 2013
[139.46] Tue May 21 11:35:56 Europe/Dublin 2013

我的模拟器的时间设置为 11:35，所以第三条语句 - DateParser.stringToDate()- 似乎在某个地方失败了。

这是我的实现：

public static Date stringToDate(String date) {
    long l = HttpDateParser.parse(date);
    Date d = new Date(l);

    return d;
}

由于我nowString包括时区，因此我希望HttpDateParser.parse()将其考虑在内，但似乎并非如此。

我该如何纠正？

4

1 回答 1

1

HttpDateParser.parse()记录在案以处理“GMT”或“TZD”，我认为它是“时区指示符”。我怀疑这应该是（可怕的，模棱两可的）缩写格式 - 例如，可能值得尝试解析

21 May 2013 11:35:56 BST

看看你会得到什么。这至少会让您在诊断HttpDateParser. 在我看来，保留时区的 TZDB ID 是一个更好的主意，但您可能需要编写自己的解析代码。但是，您仍然需要处理本地时间的歧义，因为 DST 转换导致特定的本地时间出现两次。

在您的情况下，输入或预期输出是什么并不完全清楚 - 您对格式有多少控制权。我会尽量使用 ISO-8601，如果你需要一个时区标识符，也可以使用。（如果您只是想表示一个瞬间，我会使用 UTC 瞬间的 ISO-8601 表示，并带有一个 Z 后缀来表示 UTC。）

于 2013-05-21T10:51:36.910 回答