【发布时间】:2014-09-12 10:12:13
【问题描述】:
首先简要总结一下我的问题,然后在下面进一步详细说明。
我有一个日历日期,时间为 00:00:00,因为它对业务不重要。该值被发送到 Web 服务,该服务生成一个 XML,其中该值以以下格式结束:2014-09-12T07:55:07.000Z。我注意到这是转换为 +0 时区 (UTC) 的原始值(我们的是 CET,+1,但目前 CEST,+2,因为 DST)。
我目前不知道读取 XML 的系统是否会考虑时区,或者会提取 2014-09-12 并假设它位于 +2 时区。
我注意到在 XML 中发送“2014-09-12 00:00:00”本地时间 (tz +2) 的结果是 2014-09-11T22:00:00.000Z。不足为奇,它转换了它......但如果它被其他系统解释为原样,它会认为日期比它应该的早一天。
可以做些什么来确保这得到预期的解释?
我正在考虑使用中午而不是午夜来确保时区转换不会影响解释,但这感觉像是一个肮脏的把戏。或者也许我应该作弊并将日历时区设置为 +0,以便在放入 XML 时不会时移?
问答
为什么要“向网络服务发送日历”?
应用程序在 Coldfusion 7 中。为了与 SOAP Web 服务进行通信,服务器会生成一组 Java 类,这些类符合 Web 服务预期的参数定义。该论点显然是一个具有许多属性和子属性的大对象。因此,实例化主 Java 类并使用 setter 和其他类的进一步实例化来“填充”所有属性。
您有使用日历吗?
是的,Java 对象定义不能更改。它需要所有日期的日历。
2014-09-11T22:00:00.000Z 格式是什么?
我不知道。这似乎是最终系统对日期的期望。
你应该使用 JODA
除非 JODA 类扩展 Calendar 并且与 Java 1.3(Coldfusion 服务器上的当前 Java 版本——是的,它很旧)兼容,否则我怀疑它会起作用。
你可以在其他系统上做多少?
另一个系统由不同的团队负责,显然很难改变。我希望必须在我们的应用程序中找到解决方案。
【问题讨论】:
-
这个Date time String + TimeZone也许对你有帮助
-
只是为了澄清您的一个问题:“2014-09-11T22:00:00.000Z”是 ISO-8601 格式的日期时间:en.wikipedia.org/wiki/ISO_8601。您的问题措辞很好,但不清楚您是否可以控制 Web 服务?听起来您的问题就在那里,因为它将日期视为日期/时间。普通的旧 DATE 不应考虑 TZ 偏移。我认为要解决这个问题,您应该将日历对象的 TZ 设置为 UTC,然后它将匹配 web 服务 ([Z]ulu == UTC)
标签: java coldfusion timezone