将 Sharepoint 时区信息转换为 Java 时区答案

【问题标题】：Converting Sharepoint TimeZone information to a Java TimeZone将 Sharepoint 时区信息转换为 Java 时区
【发布时间】：2014-03-13 20:48:53
【问题描述】：

我希望将 Sharepoint TimeZone 信息转换为 Java TimeZone 对象，以便与使用 Sharepoint REST API 的应用程序一起使用。我知道 Sharepoint 以 UTC 格式存储它的所有时间戳，但是在使用 REST API 时，返回的一些时间戳是时区调整的，而有些则不是。两者的格式相同，但正如您所料，UTC 值以“Z”结尾，而时区调整值则不是。因此，将它们转换为 Java DateTime 对象很容易，但如果我想始终如一地将 UTC 值返回给我的调用者，我将不得不将“非 Z”值调整为 UTC。 Sharepoint 允许我为 Sharepoint 服务器获取配置的 TimeZone 信息，但我需要的是从该信息到 Java TimeZone id 的映射。 Sharepoint 通过 REST 提供的功能如下所示：

说明：(GMT-07:00) 山区时间（美国和加拿大）偏差：420 日光偏差：-60 标准偏差：0

它没有提供任何可能表明 DST 何时开始等的信息，但我认为只要我可以将 Sharepoint“描述”映射到 Java TimeZone id，我就不必担心这一点。因此，我希望有人之前遇到过这种需求，或者可能对我如何从 Sharepoint 的 REST API 获得所需的 UTC 值提出其他建议。

【问题讨论】：

大量网络搜索。 :) 我发现了类似的事情，人们试图将 Exchange TZ（在他们提供的信息和他们使用的名称方面与 Sharepoint 版本不同）映射到 Java TimeZone ids 和一个获取 Olsen 值并将它们映射到的映射器Java 时区 ID。我对微软甚至没有在他们自己的产品中遵循标准并不感到惊讶，但我很惊讶他们至少没有为应用程序开发人员提供一种将他们的非标准标识符映射到某个标准的方法。所以，除了坐下来尝试破解我自己的地图，别无其他。
使用 Sharepoint，您可以使用 <DateInUtc> 发出请求，询问时间为 UTC（请参见：msdn.microsoft.com/en-us//library/office/…）。这样你就可以更轻松地处理它。
谢谢艾姆，这太诱人了。我将不得不看看这是否可以通过 GET 发送。有趣的是，对于文件条目，我可以获得 TZ 调整版本（“修改”和“创建”）和非 TZ 版本（“上次修改”和“创建”或类似的东西，我在路上 ATM 所以我没有确切的名称和位置可供参考）。但是对于文件夹，我只能获得 TZ 调整后的版本（与文件具有相同的元素名称）。无论如何，我会看看是否有一些有效负载正文选项或者我可能会使用的查询字符串中的某些内容。

标签： rest sharepoint timezone

【解决方案1】：

Java 使用IANA time zones。

在CLDR supplemental data 中存在 Microsoft Windows 到 IANA 时区的映射。

但是，Sharepoint 时区与常规 Windows 时区并不完全相同。它们不使用 Windows 注册表中的字符串时区键（或通过 .NET 的 TimeZoneInfo 类的 Id 属性），而是使用特定于 Sharepoint 的整数 ID。您可以找到部分列表here，以及更新的（非官方）列表here。

Sharepoint 时区描述与 Windows 时区的DisplayName 大致匹配，但不是完美匹配。完全有可能某些 Sharepoint 时区未定义为 Windows 时区。

假设您将每个 Sharepoint SPTimeZone 数字 id 映射到 TimeZoneInfo id，那么您可以使用 CLDR 数据从那里转换为 IANA 时区。如果您可以运行 .NET 代码，那么您可以使用 Noda Time 库as described here 轻松做到这一点。

更新

我继续将这些映射到合理的等价物。这些不能保证 100% 准确，但我认为它会满足您的需求。

CSV spreadsheet for the full mapping
JSON for SharePoint ID to IANA TZ name - 准备好以任何语言使用

这些大多使用大致等效的 Windows 时区进行匹配，然后使用主要 CLDR 映射与 IANA 时区匹配。唯一的例外是：

SharePoint 区域 33 和 81 是独立的，但与单个“SA 西部标准时间”窗口区域相匹配。它们分别映射到 IANA 区域 America/La_Paz 和 America/Manaus。
SharePoint 区域 41 和 92 是独立的，但与单个“马加丹标准时间”窗口区域相匹配。它们分别映射到 IANA 区域 Asia/Magadan 和 Asia/Kamchatka。

【讨论】：

马特，多么棒的回应！非常感谢您提供如此详尽的映射。我似乎不太可能让 Sharepoint 只返回我的 UTC 值（尽管基于 AymKdn 的评论和上面的链接，我仍然抱有一点希望），但这将使我能够快速创建自己的映射器。再次感谢！
Matt，我在下面添加了一些从我的 Sharepoint 2013 环境中获得的内容。您提供的列表是来自 Sharepoint 2010 的吗？我还没有完成我的 Sharepoint 2010 系统的设置来试用它，但我想知道他们是否会减少 10 个时区。无论如何，您如何看待我为这 10 个建议的映射？其中有几个有点“最佳猜测”。
我用新区域更新了 GIST 链接。另请参阅您的答案中的我的编辑和 cmets。

【解决方案2】：

我已经开始使用 Matt 的映射，它们看起来很准确。但是，我注意到 Sharepoint 2013 在 Matt 提供的列表末尾还有 10 个。所以，在这里使用可爱的 IANA 时区列表，http://en.wikipedia.org/wiki/List_of_tz_database_time_zones 我已将这些添加到 Matt 的列表中，这是我从 IANA 列表中的最佳猜测（是的，只是一个最佳猜测，所以如果您有反馈，请告诉我）。

"SharePoint ID","SharePoint Description","IANA Time Zone"
"95","(UTC-11:00) Coordinated Universal Time-11","Etc/GMT+11"
"96","(UTC-02:00) Coordinated Universal Time-02","Etc/GMT+2"
"97","(UTC+12:00) Coordinated Universal Time+12","Etc/GMT-12"
"98","(UTC+02:00) Damascus","Asia/Damascus"
"99","(UTC+12:00) Magadan","Asia/Magadan"
"100","(UTC+03:00) Kaliningrad, Minsk","Europe/Kaliningrad"
"101","(UTC+02:00) Istanbul","Europe/Istanbul"
"102","(UTC+06:00) Dhaka","Asia/Dhaka"
"103","(UTC-03:00) Salvador","America/Bahia"
"104","(UTC+02:00) E. Europe","Europe/Chisinau"

【讨论】：

...作为“最佳猜测”的一个例子...在东欧时区的中心，您真的无法比伊斯坦布尔更多，尽管该地区有很多选择从希腊雅典到芬兰赫尔辛基。
我对你的猜测做了一些修改。一般来说，Etc/GMT... 区域应该用于固定偏移区域。（名称中的符号故意颠倒了。）其他更改基于 CLDR 映射。
最后一个，104 区，有点奇怪，因为它根本不符合任何现实世界的时区，所以在 IANA 数据库中没有对应的条目。 CLDR 曾经将其列为映射到Asia/Nicosia（塞浦路斯），但那是determined to be incorrect，最近已更改。有人可能会争辩说，如果用户拥有 SharePoint TZ 104，或者他们设置了“E. Europe”时区，那么他们这样做是错误的。
再次，非常感谢。固定偏移映射完全有意义。如果有人选择这些，他们必须在某个异常区域，严格的固定偏移是最佳选择。另外，我看了你提到的票，这是有道理的。对我来说，这听起来像是，而不是抛出异常，我最好的选择是将它映射到“Etc/GMT-2”（以防万一，因为我只是一个消费者），但这对你的 GIST 来说是有意义的保持未指定，因为这看起来像当前的官方状态。
当然，除了 Etc/GMT-2 没有 DST，而“E. Europe”有，只是没有任何与 current DST 完全一致的东西规则。我很惊讶在列表的末尾看到它。它可能仅出于历史原因而存在。您可能可以继续使用Asia/Nicosia，因为它每年两次只会关闭一个小时，但正确的响应可能是退回错误以强制用户更新到更合理的时区。