我在 Visual Studio 2015 中使用 ServiceStack 4.5.6。 在我目前的情况下,我正在使用 SS 作为客户端。 REST 服务器由第三方公司用 Java 编写。 我编写了模型类、DTO 等来匹配服务器的路由。
但是现在我遇到了以下问题: 交换整数或字符串没有问题。但是似乎真的很难交换 DateTime 值。
Java 似乎使用与 C#/ServiceStack 不同的 DateTime 格式字符串,我现在找不到通用的字符串。
以下是我从服务器开发者那里得到的一些例子:
Java:
2012-06-30T12:30:40+01:00
2012-06-30T12:30:40Z
2012-06-30T12:30:40Z[GMT]
2012-06-30T12:30:40Z[UT]
2012-06-30T12:30:40Z[UTC]
2016-11-05 13:45
2016-05-15 20:15:23.340
所以在大多数情况下,Java 会添加一个 Z 或 [Timezone]。 我无法使用 ServiceStack 完全生成这些格式中的任何一种。
例如使用以下代码:
using (var scope = JsConfig.BeginScope())
{
scope.DateHandler = DateHandler.ISO8601;
return client.Post(request);
}
我得到了这个结果
2018-04-09T17:14:19.1201876+02:00
这几乎看起来像第一个 java 示例 - 但纳秒太多了。
我知道,我可以使用自定义格式,如下所述:ServiceStack - Is there a way to force all serialized Dates to use a specific DateTimeKind? 是否可以只对特定的 JsonServiceClient 使用这种自定义格式?我无法在我的整个应用程序中全局使用它。
最好的问候,丹尼尔
最佳答案
ISO 8601
我不能告诉你确切的细节,但我应该说你最好的选择是 ISO 8601 格式,国际标准。您的示例字符串遵循或接近此标准,因此我希望它可行。
Java:您的前两个示例 2012-06-30T12:30:40+01:00
和 2012-06-30T12:30:40Z
是 ISO 8601 . Z
是表示偏移量 0 的常用方法,它应该不会在任何地方造成任何问题。下一个示例中带时区的方括号是特定于 Java 的,除此之外它们也符合 ISO。如果您收到这样的字符串,您将不得不去掉括号或尽可能地解析字符串并忽略任何未解析的字符。据我所知,日期和时间之间缺少 T
的字符串不符合要求。
ServiceStack:2018-04-09T17:14:19.1201876+02:00
正好是 ISO 8601。 Java 接受这种格式应该没有问题。小数位数是自由的(并且它们是可选的,允许存在或不存在)。
OffsetDateTime odt = OffsetDateTime.parse( "2018-04-09T17:14:19.1201876+02:00" ) ;
我不知道 ServiceStack,显然我也不知道那个特定的 Java 服务器,所以这是我能得到的最接近的东西。
关于java - C# ServiceStack 和 Java 之间的日期时间格式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49736943/