让格式化程序解析字符串
问题是你的“dateToIso”方法。没必要这样。这日期时间格式化程序对象的工作是在给定正确的格式时解析字符串。您确实给出了正确的格式。然后你将字符串转变为不同的格式!
解决方案: (a) 终止 dateToIso 方法。 (b) 删除对该方法的调用。只需将原始字符串传递给parseDateTime
.
附带问题:您忽略了时区问题。因此,在解析该字符串时,Joda-Time 将假设该日期时间事件发生在 JVM 的默认时区。因此,使用相同的输入但在具有不同时区设置的另一台计算机/JVM 上运行相同的代码将导致不同的输出。可能不是你想要的。经验教训:始终指定时区而不是依赖默认值。
还有另一个问题:您引用的错误是一个不同的问题,从 Joda-Time 转换为 Google 时间。请继续阅读。
阅读文档
如果您正在尝试转换您的org.joda.time.DateTime
反对com.google.api.client.util.DateTime
对象,只需查看JavaDoc。在那里您将看到 Google DateTime 的构造函数采用 java.util.Date。 Joda-Time 有一个内置的toDate
方法转换为 java.util.Date 对象以与其他类进行互操作。
食物链
创建一个像这样的对象食物链:
org.joda.time.DateTime → java.util.Date → com.google.api.client.util.DateTime
一些未经测试的代码...
org.joda.time.DateTimeZone = org.joda.time.DateTimeZone.forID( "Africa/Johannesburg" );
org.joda.time.DateTime jodaDateTime = new DateTime( timeZone );
// Convert from Joda-Time to old bundled j.u.Date
java.util.Date juDate = jodaDateTime.toDate();
// Convert from j.u.Date to Google Date.
com.google.api.client.util.DateTime googleDateTime = new com.google.api.client.util.DateTime( juDate );
毫秒
或者,您可以提取并传递毫秒。
一般来说,我建议尽可能避免直接处理毫秒。使用毫秒可能会造成混乱、草率且容易出错。毫秒计数很难调试,因为人类无法轻易破译日期时间的含义long
。而 Joda-Time 和 java.util.Date 使用 UNIX 纪元以来的毫秒数作为其内部时间跟踪机制......
- 部分软件使用seconds or 纳秒而不是毫秒。
- 有些软件使用其他epochs而不是Unix时代.
走向另一个方向
[以下部分假设 Google 已用更新的 API 取代了问题引用的 API。不确定这个假设是否正确。]
当从一个com.google.gdata.data.DateTime对象 Joda-Time DateTime,我会使用由getValue
方法。请注意,它返回的是 64 位long
,而不是 32 位int
.
确保将所需的时区分配给 Joda-TimeDateTime而不是依赖于隐式分配 JVM当前默认时区.
long millisecondsFromUnixEpoch = myGoogleDateTime.getValue();
org.joda.time.DateTimeZone zone = DateTimeZone.forID( "Africa/Johannesburg" );
org.joda.time.DateTime jodaDateTime = new DateTime( millisecondsFromUnixEpoch, zone );
Google API 提供了一些其他选择。
toStringRfc822
您可以致电toStringRfc822方法生成一个由 Joda-Time 解析的字符串。不幸的是,RFC 822 解析起来很尴尬且含糊不清。除其他错误外,它使用非标准非唯一的 3-4 字母时区代码而不是正确的时区名称。由于这些代码含糊不清,Joda-Time 拒绝尝试解析这些代码。我假设 Google 将其包含在这里只是为了向后兼容旧的 API/库。现代互联网协议已转向 ISO 8601。
toUiString
也许你可以打电话给toUiString方法创建一个由 Joda-Time 解析的字符串。不幸的是,他们的文档未能解释该方法使用什么格式。
toString
您可以致电toString
被记录为产生的方法xs:dateTime
细绳。该文档未能准确解释,但我猜他们的意思是XML 架构规范包含 ISO 8601。您可以尝试此方法来查看它会生成什么。如果您想保留嵌入在 Google 对象中的 UTC 偏移量,它可能会很有用。但请记住,时区不仅仅是 UTC 的偏移量,因此您仍然应该将所需/预期的时区分配给 Joda-Time DateTime 对象。因此,我不确定这是否比仅仅通过long
count-from-epoch 到 Joda-Time DateTime 的构造函数。
java.time
现在Java 8发布后,也许 Google 可能会对其 API 进行现代化改造以使用java.time包.
请注意,java.time 扩展了 ISO 8601 格式以附加时区的正式名称,这是一个非常有用的想法。