👔 ◾️ 👨🏽‍✈️ ロシア、ベラルーシ、ウクライナのタイムゾーンの変更 🤳🏼 😡 🧕🏼

おそらく既に聞いたように、2011年の秋に、いくつかの州は、領土の時間を計算する手順を変更し、夏時間への季節的な切り替えをキャンセルすることを決定しました。

これらの州のリストでは、ロシア、ベラルーシ、ウクライナ、部分的に認められた州：アブハジアと南オセチア、および認識されていないトランスニストリアの州。つまりこれらの国のすべてのタイムゾーンで、季節的な追加のシフトなしに、UTCに対して年間を通して固定のシフトがあります。

（注：ウクライナは最初に夏時間なしでUTC + 3に切り替えることを決定しましたが、その後、以前の決定をキャンセルし、これまでの季節のクロック転送で時間を計算する前の手順に戻りました。

サーバークロック

この記事では、採用されたタイムゾーンの変更の本質を説明し、ITシステム（企業インフラストラクチャ、サーバー、ワークステーション、サービス、アプリケーションなど）に関する問題の技術面について説明します。これらの変更に関連して生じる多くの基本的な質問に答えようとします。

-タイムゾーンの変更によって影響を受ける可能性のあるITシステムは何ですか？

-これはどのような問題を引き起こす可能性がありますか？

-可能な場合、問題を回避するためにこれを準備する方法は？

多くのシステム/アプリケーション管理者は、一部のアプリケーション/サービス開発者と同様に、この資料に精通していると便利だと思います。そして、コメントでこの情報を議論し、補足することに興味のあるすべての人を招待します。

内容

「夏」または「冬」の時間をキャンセルしましたか？

時間の計算を変更するための法的枠組み

新しいタイムゾーンは何時ですか？

ロシアのタイムゾーンのリスト

ロシア連邦のタイムゾーンを形成するロシア連邦の領土の構成

ウクライナとベラルーシのタイムゾーン

他の国の夏時間はどうですか？

夏時間の使用可能性

タイムゾーンの変更による問題は何ですか？

どうする

しかし、NTPまたはGPSと同期した正確な時間がある場合はどうなりますか？

さまざまなオペレーティングシステムでのタイムゾーン情報（TZI、タイムゾーン情報）の更新

UnixシステムとUnixライクなオペレーティングシステム

シスコネットワーク機器

モバイルOS

MS Windows

レガシーWindowsシステムの更新

さまざまな地域のWindowsでのタイムゾーンの再構成の機能

チュコトカ、カムチャッカ

マガダン

サハリン州とヤクーチア

サマラ、イジェフスク（ウドムルト共和国）

カリーニングラード

ベラルーシ

MS Active Diectoryドメインコントローラーのタイムゾーンを更新する

MS Exchangeサーバーのタイムゾーンの更新

MS Sharepointサーバーのタイムゾーンの更新

OSおよびソフトウェアのタイムゾーン情報を更新する必要があるのはいつですか？

「夏」または「冬」の時間をキャンセルしましたか？

ニュース記事の一部のジャーナリストは、ロシアとベラルーシのタイムゾーンのこれらの変更を「冬時間の廃止」と解釈しました。フィリピンの観点から見ると、すべてがまさにそのように見えます。春の夏時間はこれらの国々で行われましたが、逆の移行はありません。したがって、時間は常に「夏」であり、「冬」の時間はもうないようです。

しかし、正式には、「冬時間」は存在しません。夏時間（通常は3月下旬から10月下旬）に標準時間にさらに1時間追加される夏時間（DST）を採用している国もあります。

そのため、ロシアとベラルーシのすべてのタイムゾーンで、2つのイベントが発生します。

1）継続的に標準時間にさらに1時間追加されます。

2）季節ごとの時計の移動はキャンセルされます（つまり、夏時間はキャンセルされます）。

したがって、2011年10月29〜30日の夜、ほぼすべての欧州諸国が夏時間から標準時間に現地時間を戻すために時計を1時間戻す場合、ロシアとベラルーシでは時計が転送されません。新しい受け入れられた時間は、これらの地域で以前に稼働していた夏時間とちょうど一致します。将来、これらの国では、夏時間は移行されません（これらの決定が法的に取り消されない限り）。

時間の計算を変更するための法的枠組み

ロシアでは、これらの変更は、2011年8月31日のロシア連邦政令No.725 「各タイムゾーンを形成する領土の構成、タイムゾーンでの時間の計算手順、およびロシア連邦政府の特定の決定の無効としての認識に関する」によって導入されました* 2011年9月6日に発効しました）。

ベラルーシでは、これらの変更は2011年9月15日のベラルーシ共和国閣僚理事会令1229号「ベラルーシ共和国の領土での時間の計算について」（ PDF ）で紹介されました。

ウクライナでは：

2011年9月20日-ウクライナのヴェルホフナラダは、政令第3755-VI 「ウクライナでの時間の計算手順の変更について」[ DOC ]（2011年9月29日にウクライナのヴェルホフナラダの議長が署名）を採択しました。この法令は、UTC + 3時間を確立し、ウクライナ全体での季節的な時計の転送を廃止しました。 UTC + 1年を通して3時間節約。

2011年10月18日-ウクライナのヴェルホフナラダは、新しいウクライナ政令3914-VI 「ウクライナの時間の計算手順の変更に関するウクライナのベルホフナラダの判決について」[ DOC ]（2011年10月19日にウクライナのヴェルホフナラダの議長によって署名）を採択しました。これは、2011年9月20日に採択されたVerkhovna Rada No. 3755-VIの以前の決議を認識しています。したがって、ウクライナのVerkhovna Rada No. 3914-VIのこの決議の発効後、現地時間を計算するための以前の手順が戻りました：標準時間（冬）UTC + 2および夏時間UTC + 3。

ウクライナが夏時間（UTC + 3）から標準時間（UTC + 2）に戻った2011年10月30日以降、ウクライナの閣僚はウクライナのヴェルホフナラダに請求書を転送し、ウクライナの季節の夏時間の切り替えをキャンセルします時間。この決定が採択されると、2012年3月末のウクライナは夏時間に切り替わることはなくなり、ウクライナでは年間を通してUTC + 2（DSTなし）の固定時間が設定されます。

アルメニアでは、報道によると、季節ごとの夏時間と夏時間の移転の廃止に関する法案が準備されていますが、アルメニア議会（国会）ではまだ法的に採択されていません。 2011年10月30日、アルメニアが1時間前に夏時間（UTC + 5）から標準時間（UTC + 4）に時計を設定することは既に知られています。しかし、2012年3月まで、アルメニアでの季節的な時計の譲渡を廃止する法律が最終的に承認され、施行されることが予想されます。これが発生した場合、2012年3月末にアルメニアは夏時間に切り替わることはなくなり、UTC + 4（DSTなし）は一年中固定されます。

2011年にタイムゾーンの変更を確立するアブハジアと南オセチアの公式立法行為とは関係ありません。私の知る限り、そのような文書はまったく存在しません。これらの国では、独立宣言の際に現地時間とモスクワ時間の対応が確立されただけです（政治的理由により）。したがって、2011年のモスクワ時間の変更と、ロシア、アブハジアおよび南オセチアの夏時間への切り替えの拒否により、時間はモスクワとの類推によっても変化します。したがって、現在アブハジアと南オセチアでは、夏時間だけでなく、一般的に通年で、現地時間はジョージア州全体（UTC + 4）の現地時間と一致します。

トランスドニエストモルダビア共和国では、これらの変更は2011年10月10日のPMR大統領令第770号「トランスドニエストモルダヴィア共和国の領土における季節時間への移行の廃止について」（2011年10月18日に施行）によって導入されました。さらに、モルドバの残りの地域は、その地域の時間を計算する手順を変更しないため、2011年10月30日、モルドバは標準（冬）時間に戻ります。

* 注：2011年のロシアのタイムゾーンの変更に関するインターネットの一部の記事では、ロシアのタイムゾーンの時間を計算する新しい手順、およびロシア連邦の季節の時計の移動の廃止が、ロシア連邦の連邦法「時間計算」によって確立されたと誤って示されています、2011年6月にロシア連邦大統領（D.A. Medvedev）によって署名されました。 ただし、実際にはそうではありません。

実際、「時間の計算について」ロシア連邦の連邦法があります（2011年6月3日付107-）：

-下院で採択：2011年5月20日。

-連邦評議会の承認：2011年5月25日。

-ロシア連邦大統領の署名：2011年6月3日。

- 公開日：2011年6月6日。

-2011年8月7日に発効

しかし、彼だけがロシアのタイムゾーンの境界を確立せず、各タイムゾーンの時間を決定せず、夏時間への季節的移行の廃止を確立しません。

この連邦法は、時間を計算するための一般的な定義と原則（年数、うるう年、暦日/週/月/年、日/年の始まりと終わり、時間帯と現地時間、正確な時間に関する情報の配信方法など）。

法律はまた、ロシア連邦の地域を時間帯に分割すること、時間帯の境界を設定すること、およびこれらの時間帯の時間を計算することに関する特定の決定がロシア連邦政府によって行われると述べています。これらの目的のために、これらの問題を規制するRF政府の「各タイムゾーンを構成する領域の構成とタイムゾーンでの時間の計算手順、およびロシア連邦政府の個々の法令の承認に関する」法令が規制されました。 そして、ロシア連邦のタイムゾーンに関するすべての詳細が示されているのは、まさに政府の命令です。

a）タイムゾーンの境界が確立されています。

b）ローカル（ローカル）時間のシフトが各ゾーンで確立されます。

c）ロシア連邦全体の季節的時計移動（DST）のキャンセル。

しかし、何らかの理由で、ロシア連邦の新しいタイムゾーンと夏時間の廃止が連邦法「時間の計算について」に導入されたと誤って判断した人もいます。また、状況を理解していない一部のウィキペディア編集者は、早ければ2011年6月にロシアのタイムゾーンに言及したウィキペディアの記事を積極的に修正し、すでに新しい時間と夏時間がないことを示しました。 しかし、実際には、そのような改正の法的根拠はありませんでした。 このような変更の法的根拠は、2011年8月31日のロシア連邦政府第725号第725号が施行された2011年9月6日のみに現れました。

新しいタイムゾーンは何時ですか？

ロシアのタイムゾーンのリスト

_{表1ロシアのタイムゾーン*のリスト（2011年9月）}

いや	現地時間	UTCオフセット	DST	Int。名前	Int。略語。
1	モスクワ時間-1	UTC + 03：00	-	カリーニングラード時間	USZ1、FET（MSK-1）
2	モスクワ時間	UTC + 04：00	-	モスクワ時間	Msk
3	モスクワ時間+2	UTC + 06：00	-	エカテリンブルグ時間	YEKT（MSK + 2）
4	モスクワ時間+3	UTC + 07：00	-	オムスク時間	OMST（MSK + 3）
5	モスクワ時間+4	UTC + 08：00	-	クラスノヤルスク時間	KRAT（MSK + 4）
6	モスクワ時間+5	UTC + 09：00	-	イルクーツク時間	IRKT（MSK + 5）
7	モスクワ時間+6	UTC + 10:00	-	ヤクーツク時間	YAKT（MSK + 6）
8	モスクワ時間+7	UTC + 11:00	-	ウラジオストック時間	VLAT（MSK + 7）
9	モスクワ時間+8	UTC + 12:00	-	マガダン時間	MAGT（MSK + 8）

^{*現在、ロシアでは正式にタイムゾーンではなく、タイムゾーンと呼ばれています}

ロシア連邦のタイムゾーン（2011年9月）

ロシア連邦の時間帯を形成するロシア連邦の領土の構成：

1時間帯-MSK-1（UTC + 03：00）：

カリーニングラード地域。

2時間ゾーン-MSK（UTC + 04：00）：

モスクワとロシアのヨーロッパ全体（地域の完全なリストについては、政府決議第725を参照）。

3時間ゾーン-MSK + 2（UTC + 06：00）：

バシコルトスタン共和国、ペルミ準州、クルガン州、オレンブルク州、スベルドロフスク州、チュメニ州、チェリャビンスク州、ハンティ・マンシ自治管区-ウグラおよびヤマロ・ネネツ自治管区。

4時間目ゾーン-MSK + 3（UTC + 07：00）：

アルタイ共和国、アルタイ準州、ケメロヴォ地域、ノボシビルスク地域、オムスク地域、トムスク地域。

5時間ゾーン-MSK + 4（UTC + 08：00）：

ティヴァ共和国、カーカシア共和国、クラスノヤルスク準州。

6時間帯-MSK + 5（UTC + 09：00）：

ブリヤート共和国とイルクーツク地方。

7時間帯-MSK + 6（UTC + 10:00）：

ヤクーツク（ヤクーチアの地域の完全なリストについては、政府決定No. 725を参照）、トランスバイカル準州、およびアムール州を含む、サハ共和国（ヤクーチア）のほとんど。

8時間ゾーン-MSK + 7（UTC + 11:00）：

沿海地方、ハバロフスク地方、ユダヤ自治州、サハ共和国（ヤクーチア）の一部（ヴェルホヤンスク、オイミャコンスキー、ウスチヤンスキーウルス（地区））、サハリン州（セベロクリルスキーを除くすべての地区）の一部。

9番目のタイムゾーン-MSK + 8（UTC + 12:00）：

カムチャツカ地方、マガダン州、チュコトカ自治管区、サハ共和国（ヤクーチア共和国）の一部（アビスキー、アライホフスキー、ヴェルフネコリムスキー、モムスキー、ニジネコリムスキー、スレドネコムスキールーセス（地区）、サハリン州（北クリル地域）の一部。

ウクライナ、ベラルーシ、アブハジア、北オセチアおよびPMRのタイムゾーン

ベラルーシのタイムゾーンは1つのみです。 ミンスク時間（UTC + 03：00） -ヨーロッパ東部時間（FET）。

ウクライナのタイムゾーンは1つのみです。 キエフ時間（UTC + 03：00） -東ヨーロッパ時間（FET）。ウクライナはこれまでの時間計算の以前の順序に戻りました。冬-標準キエフ時間（UTC + 02：00）、夏-夏キエフ時間（UTC + 03：00）。

アブハジアおよび南オセチアの領土のタイムゾーン： モスクワ（またはトビリシ）時間（UTC + 04：00） 。

トランスドニエストモルダヴィア共和国の領土のタイムゾーン： （UTC + 03：00） -東ヨーロッパ時間（FET）。

上記のように、リストされているすべてのタイムゾーン（ウクライナを除く）は夏時間なし（DSTなし）、つまり UTCに対して示されるシフトは、これらのタイムゾーンでは一年中一定です（冬と夏は同じ色で）。ウクライナでは、当面の間、季節的な時間の移行のルールが有効になりますが、ほとんどの場合、ウクライナは夏時間に切り替えることなく、今後数か月でUTC + 2に切り替わります。なりません。

ロシア、ベラルーシ、北オセチア、アブハジアでは、これらのタイムゾーンの変更はすでに発効しており、すでに実施されています。

他の国の夏時間はどうですか？

今年だけ夏時間なしで新しいタイムゾーンが設置されたロシアとベラルーシの領土に加えて、次のソビエト連邦以降の州では夏時間はありません：ジョージア、カザフスタン、ウズベキスタン、トルクメニスタン、タジキスタン、キルギスタン。ソビエト後の共和国のうち、夏時間はこれまでリトアニア、ラトビア、エストニア、モルドバ、アゼルバイジャン、ウクライナ、アルメニアの7つの州でのみ残っています。さらに、ウクライナとアルメニアは2011年秋に最後に時計を移管し、その地域の季節の時計の移管を廃止する法律を可決し、年間を通じて現在の標準時の一定の運用を統合することが予想されます。

ロシアが2011年に夏時間のキャンセルを発表した後、アブハジアと南オセチア（一部に認められた州）も、現在は夏時間なしで1年中UTC + 4タイムゾーンがあります。すべてのジョージア州とモスクワのように。

さらに、ロシアの最も近い隣人からは、夏時間もモンゴル、中国、および日本にありません。

一般に、夏時間を使用した世界の状況は次の図に示されています。

ご覧のとおり、世界のほとんどの国では現在、夏時間は利用できません。しかし、北米とヨーロッパの大部分では、夏時間がまだ使用されています。これは、ここ（ロシアとベラルーシ）で、これらの国との時差が不安定になることを意味します（夏の差は冬の差より1時間短くなります）。最初はこれは異常であり、不便を招くかもしれませんが、その後徐々に慣れてきます（または、アメリカとヨーロッパが夏時間をやめるかもしれません）。

夏時間の使用可能性

夏時間への切り替えの妥当性についての論争は長い間続いています。当初、夏時間の1時間のタイムシフトは、日中の時間をより効率的に使用し、夜の街路や家の照明に費やす電力を節約することを目的として導入されました。そしてこれは、照明がすべての電気のコストのかなりの部分を占めていた50年前に、目に見える経済的利益を本当にもたらしました。しかし、現代の世界では、照明に費やされる電力の割合は、他のエネルギーコスト（工業生産、暖房、換気、空調）に比べてすでに小さくなっています。その結果、夏時間への切り替えによる節約は、エネルギーコストの総量でわずかです。（2007年のRAO「ロシアのUES」データによると、国内の矢印の転送により、ロシアで消費される電力の総量の約0.5％である44億キロワット時の電力が節約されます。）

さらに、熱帯緯度では、年間の昼と夜の長さはほとんど変化しませんが、極緯度では、逆に夏には極日があり、冬には極夜があります。これらの機能により、約30°〜55°の緯度帯域の地域でのみ夏時間を導入することが経済的に効果的です。悲しいかな、ロシアのほとんどはこれらの緯度の北に位置しています。

まあ、1年に2回の矢印の翻訳には十分なマイナスもあります。

-クロック転送の日にトラフィックのスケジュールのスケジュール。

-時間の移転の日における貨物運送業者の単純で経済的な損失;

-覚醒状態と睡眠パターンの変化によって引き起こされる人々の健康問題;

-搾乳/給餌時間の変更に起因する農業動物の問題。

個人的には、夏時間への移行でプラスよりもマイナスが多く見られます。したがって、夏時間の廃止は正当化されると思います。

しかし、冒頭部分で既に強調したように、この記事では季節的な時間の移動をキャンセルするための非経済的および政治的な動機に触れたいと思います。私は今、経済効率の議論とそのような決定の正当性を掘り下げたくありません。さて、まず第一に、問題の技術面を強調したいと思います。つまりこれらのタイムゾーンの変更を避けられないものと考え、ITインフラストラクチャへの影響の観点から状況を考えてみましょう。十分な歌詞があれば、技術的な部分に移ります。

タイムゾーンの変更による問題は何ですか？

一見、問題は明らかです...

ITシステム（アプリケーション/サービス）のどこかでローカル時間を使用する場合（たとえば、各クライアントのイベントの時間をローカル時間で個別に表示する場合）、システムにはローカル時間の計算に関する情報を含むデータベースが必要です。世界の各タイムゾーン。また、このデータベースがタイムリーに更新されない場合、2011年10月30日からロシアとベラルーシについて、このデータベースは現地時間の誤った計算を行います。

何らかのWebフォーラムを管理しているとします。すべてのユーザーは、プロファイルでタイムゾーンを示します（または、プロファイルで指定された決済に従って自動的に計算されます）。このWebフォーラムのデータベースにメッセージを作成する時間は、サーバー側にUTC形式で保存されます。メッセージのUTC時間までに各ユーザーにメッセージを表示する場合、表示ユーザーの現地時間に合わせて調整が行われます。さらに、この修正のサイズは、フォーラムのウェブエンジンの開発者が管理する特定のタイムゾーンデータベースに従ってサーバー側で計算されます。

また、Webフォーラムの管理者が2011年10月30日からこのデータベースを予定どおりに更新しない場合、このフォーラムのロシア語ユーザーの現地時間の計算は既に正しく機能していません。たとえば、ユーザーが指定したモスクワ時間の場合、UTC + 4は正しくシフトされ、フォーラムは以前と同様にカウントされますが、すでに間違っています：UTC + 3。

この明らかな問題は、各ITシステムの関連するタイムゾーン情報を更新するときに解決する必要があります。これは、少なくとも何らかの形で作業に現地時間を使用します。この例では、Webフォーラムで使用されるタイムゾーンデータベースを更新します。

しかし、実際には問題はもう少し深いです...

ロシアの地域でタイムゾーンが単純に変更された場合、特に問題はありません。コンピューターを別の国に移動し、クロック設定でその国の適切なタイムゾーンを選択するように見えました（1台のコンピューターの規模ではなく、その地域のすべてのコンピューターの規模になりますが、一般的な原則は同じです）。これにより、問題は発生しません。ほとんどすべてのソフトウェアは、異なるタイムゾーンで動作するように適合されています（もちろん、異なるタイムゾーンを考慮せずにすべてを現地時間に排他的に結び付けたある種の完全なbydocoderによって書かれた場合を除きます）。

ただし、この場合、ロシアのほとんどの地域（カリーニングラードを除く）では、タイムゾーンは変更されず、同じまま（同じ名前）であり、UTCを基準にしてこのゾーン内のローカル時間を計算するルールが変更されます。つまり、たとえば、モスクワ時間（MSK）がUTC + 03：00に対応する前に、同じタイムゾーンのモスクワ時間（MSK）がすでにUTC + 04：00に対応しています。さらに、モスクワ時間に従って新しいイベントの時間（たとえば、2011年12月）を計算するとき、UTC（+4）に対するモスクワ時間の新しいオフセットを使用するのが正しいでしょう。また、モスクワ時間に従って古いイベントの時間（たとえば、2010年12月）を計算するときは、古い時間を使用するのが正しいでしょうUTC（+3）に対するモスクワ時間のオフセット。この時間はモスクワ時間に対して有効でした。異なる履歴期間の現地時間の計算にこのような差別化されたアプローチを適用しない場合、そのような計算は不正確になります。

現地時間で動作する特定のITシステムが内部のタイムゾーンデータベースを使用し、すべての世界のタイムゾーンに関する最新情報をシンプルなフラットリストの形式で保存するとします。このリストでは、各タイムゾーンは、現在有効なUTCに対する特定のオフセットに一意に対応しています。つまりたとえば、「モスクワ時間（MSK）-UTC + 03：00」など。このタイムゾーンデータベースを更新すると、このリストのロシアのエントリが変更され、特に「モスクワ時間（MSK）-UTC + 04：00」になりました。

古いイベント（たとえば、2010年12月）のこのタイムゾーンデータベースを更新しないITシステムは、このデータベースから現地時間を正しく計算しますが、新しいイベント（たとえば、2011年12月）の場合、ローカルタイムを使用して計算しますこのベースはすでに間違っています。

また、新しいイベント（たとえば、2011年12月）ではこのタイムゾーンデータベースを更新するITシステムは、このデータベースから現地時間を正しく計算し、古いイベント（たとえば、2010年12月）では逆にローカルを計算しますこのベースの時間は間違っています。

つまりこの状況でタイムゾーンデータベースを更新した後でも、日付（つまり、過去の日付）を操作するときに問題が発生する可能性があります。そして、基本的なエラーは、タイムゾーンをフラットリストの形式で格納するという原則に基づいており、現在の時間にのみ関連しているという事実が原因です。

この状況で最も柔軟なソリューションは、世界の各地域の現地時間を計算するための現在のルールを保存するだけでなく、現地時間を計算するためのこれらのルールの変更履歴も保存するように、タイムゾーンのデータベースを維持することです。つまりベースは、各地域、現地時間を計算するためのルールがこの領域に作用した絶対的な時点、およびこれらのルールが他のルールに置き換えられた正確な時点で「記憶」する必要があります。現在の時点だけでなく、過去の任意の期間のすべての地域の現地時間を計算するための正しいルールを知ることで、任意の履歴期間の現地時間を使用して正確に計算を実行することができます。

これは、多くの* nixシステム（Linux、BSD、Mac OS Xを含む）で使用されているtzdataベースの構造（tzdataについての詳細を読む）です。そして、これはまさにタイムゾーンに関する情報を保存するための他の形式よりも重要な利点です。

マイクロソフトの開発者は、タイムゾーンに関する情報が単純なリスト形式で保存されており、現時点でのみ問題があると感じています。たとえば、Windowsレジストリ[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones]の異なるタイムゾーンに対応するパーティションを展開すると、それらの一部に「Dynamic DST」というサブセクションが表示されます。夏時間に切り替えるための動的に変化するルールを保存するだけで、年によってはその逆も保存されます（あるタイムゾーンでこれらのルールが近年変更された場合）。彼らは、比較的最近、異なる年の時間帯に関するこの変化する情報を保持し始めました。

しかし、Windowsレジストリのタイムゾーンデータベースを使用するすべてのソフトウェアが、これらの変更を異なる年の間正しく処理するという確信はまだありません。

さらに、さまざまな開発者会議で、パッチKB2570791をインストールした後、過去の日付の現地時間を計算する機能が誤った結果を出し始めたという苦情がすでに現れています。次に例を示します。oneおよびtwo。

Microsoft Habraブログには、開発者向けの推奨事項があります：

habrahabr.ru/company/microsoft/blog/130629

どうする

システムおよびアプリケーションの管理者は、開発者や他のIT専門家と同様に、タイムゾーンの変更に関連する問題を回避するために、事前にITシステムを準備する必要があります。

適切に作成されたITシステム（アプリケーション/サービス/ DBMS）は、通常、時間を扱うために次のアプローチを使用します

。（Unix時代の始まりから1970年1月1日00:00:00からの秒数）またはUTC。

2）時間はUnix時間（またはUTC）のみで処理（比較、加算、減算、シフト）されます。

3）現地時間が表示されるタイムゾーンに関する情報は、個別に保存されます。たとえば、現地時間の形式でユーザーに情報を提示するために、タイムゾーンはユーザープロファイルから取得されます。

4）異なる期間に世界の異なる地域で現地時間を計算するための規則に関する情報を格納するデータベース（たとえば、tzdataデータベース）は、個別に絶えず更新されます。

5）正確なUnix時間（またはUTC）、ローカルタイムゾーンの名前、および特定のタイムゾーンのローカル時間を計算するためのルールを持つベースを使用すると、任意の期間の任意の地域でローカル時間の計算を常に正確に実行できます。

現地時間でアクションを実行するには、特定の期間の特定のタイムゾーンで現地時間を計算するためのルールに従って、まずUnixタイム（またはUTC）に転送され、その後のみ処理されます。処理結果を現地時間形式で表示する必要がある場合、特定の期間の特定の時間帯で現地時間を計算するためのルールに従って、結果は指定した時間帯の現地時間に再計算されます。

すべてのイベントの正確な時間は、クライアントではなくサーバーで記録する必要があります（Unix時間またはUTC）。さらに、サーバーはNTPサーバー（または他の時刻同期のソース）からの正確な時刻を持ち、現地時間で再計算を実行するためにタイムゾーンの最新のデータベースを持っている必要があります。

tzdataを使用するUNIXシステムの世界では、通常、現地時間で作業するロジックはこのように編成されています。したがって、tzdataを更新するのに十分であり、何も腐食しません。

しかし、残念なことに、すべてのアプリケーションとシステムが、このようなうまく構築された仕事の論理を自慢できるわけではありません。どこかに松葉杖と自転車があるかもしれません。これは、タイムゾーンの変更がどこでもスムーズに行われないことを意味します。

一般的な総行動計画は次のとおりです。

オペレーティングシステム、DBMS、およびその他のソフトウェアで利用可能なタイムゾーン情報の更新を確認します。このソフトウェアのメーカー/サプライヤーからの公式アップデートの推奨事項をお読みください。
, , ( ).
- // , , /*/.
( , tzdata), «», .
ITプロフェッショナルの場合、使用するソフトウェアソリューションの開発者および管理者の会議やフォーラムを表示することをお勧めします。タイムゾーンの更新に関連して発生する可能性のあるレーキについて事前に知るために、同僚と経験を交換することは有用です。
その後、必要なOSおよびソフトウェアの更新をダウンロードして適用します。
起こりうる問題に備え、それらを回避する方法について考えてください。

*たとえば、seriyPSによると、Pythonはpytzライブラリを使用してタイムゾーンを処理します。最新バージョン2011k。現在インストールされているpytzバージョンを表示するスクリプト：

import pytz print pytz.__version__

pytzライブラリを更新するには：

sudo pip install -U pytz

または

sudo easy_install -U pytz

しかし、NTPまたはGPSと同期した正確な時間がある場合はどうなりますか？

実際には、正確な時刻ソース（NTPサーバー、GPS受信機、原子時計）が正確な絶対時刻（Unix時間）を提供します。この場合、それはまったく変化せず、すべて同じように均一かつ継続的に継続します。以前と同じように受け取り、タイムスケールで中断またはジャンプすることなく受け取り続けます。すべての正確な時刻のソースは、単一の絶対時刻をレポートします。彼らは、提供された絶対時刻からローカル時刻を取得するために誰、どこで、どのルールが使用されるかを知りません。これは、正確な時間ソースの問題ではありません;この時間を既に処理しているそれらのシステム/アプリケーションはこれに従事しています。

ただし、OSまたはソフトウェアがローカル時間で動作する必要がある場合、これはOSまたはアプリケーション側の絶対時間（正確な時間のソースから受信するか、コンピュータータイマーによって独立してカウントされる）であり、必要なローカル時間に再計算されます（またはローカルから絶対時間に戻ります））また、エラーのない計算を実装し、OSおよびソフトウェアでローカル時間を正しく再計算するには、現在の世界のタイムゾーンを使用する必要があります。

つまりサーバーが正確な時刻のソースと同期しているかどうかに関係なく、タイムゾーンとローカルタイムで正しく動作するには、更新されたグローバルタイムゾーンのグローバルデータベースが必要です。つまり NTPとの同期の存在は、ITシステムのタイムゾーンに関する情報の更新に関する心配を軽減しません。

さまざまなオペレーティングシステムでのタイムゾーン情報（TZI、タイムゾーン情報）の更新

UnixシステムとUnixライクなオペレーティングシステム

異なる商用Unixシステムおよび無料のUnixライクシステム（GNU / Linuxディストリビューション、BSDシステムなど）は、世界のタイムゾーンに関する情報を保存するために異なる形式を使用します。配布キット内の一部のベンダーは、独自の元の形式（たとえば、HP-UXのtztab）でこの情報を独立して維持し、最新の状態に保ちます。

それでも、ほとんどのUnixライクなシステムは、tzdataデータベースをすべての世界のタイムゾーンに関する単一のグローバルな情報ソースとして使用しています。 tzdataで収集された情報は、ライセンスの制限（パブリックドメイン）なしですべての参加者に自由に配布されます。誰でも（ソース形式とバイナリ形式の両方で）自由に取得して、アプリケーション/ライブラリ/サービスで使用できます。そして、OSディストリビューション（特にLinux / BSD / MacOS）およびさまざまなソフトウェアの多くの開発者/ベンダーがまさにそれを行います。

オープンソースの世界では、tzdataデータベースは事実上、すべての世界のタイムゾーンとその変更の履歴に関する標準的な情報源です。 tzdataデータベースは、すべてのGNU / Linuxディストリビューション、BSDシステム（FreeBSD、NetBSD、OpenBSD、DragonFly BSD）、Solaris、UnixWare、AIX（6.1以降）、Cygwin、Mac OS Xおよび他のUnixライクなディストリビューションで使用されます。さらに、tzdataのデータは、MySQL、Oracle DB、PostgreSQLなどの多くのDBMS、およびさまざまな言語、フレームワーク、ライブラリ、モジュール：PHP5、Perl（モジュールDateTime :: TimeZoneおよびDateTime :: LeapSecond）、Pythonで使用されます（pytzモジュール）、GNU Cライブラリ（glibc）、. NET Framework（zoneinfoモジュール）、Javaランタイム環境など。

公式tzdataプロジェクトページ： http : //cs.ucla.edu/~eggert/tz/

タイムゾーンを操作するためのtzdataおよびユーティリティのソースは、ftp： //elsie.nci.nih.gov/pub/からダウンロードできます（試用期間中、FTPサーバーは一時的に閉じられます）。

すべてのtzdataプロジェクトファイルをミラーリングする： http : //tzmirror.appealingapps.de、ftp ： //tzmirror.appealingapps.de

別のミラー： ftp : //munnari.oz.au/pub

この記事を過負荷にしないために、別の記事で tzdataに関するより詳細な情報を掲載しました。

この記事の執筆時点で、tzdataの最新バージョンは2011l（2011年10月10日リリース）です。

ロシアの新しいタイムゾーンの変更はバージョン2011hからのtzdataに現れ、ウクライナとベラルーシのタイムゾーンの変更はバージョン2011kからのtzdataに現れました。

ウクライナ議会は、季節の時計の移転の廃止に関する以前の決議をすでに取り戻したため、tzdata-2011kおよびtzdata-2011lにはウクライナのタイムゾーン（ヨーロッパ/キエフ）に関する誤った情報が含まれていることがわかりました。したがって、ウクライナの場合は、古いバージョン（2011j以前）または新しいバージョン（2011m以降）を使用するのが適切です。 tzdata 2011mバージョンのリリースは、2011年10月24日に発表されました。このバージョンは、ウクライナ（ヨーロッパ/キエフ）およびTransnistria（ヨーロッパ/ティラスポリ）向けに修正する必要があります。

したがって、2011年に変更されたロシアとベラルーシのタイムゾーンに関する情報を更新する* nix-systemsでは、ベンダーが提供する対応する更新プログラムをインストールする必要があります。 tzdataを使用するほとんどのディストリビューションでは、標準リポジトリ、ポート、およびこのOSのディストリビューションで使用されるその他の組み込みディストリビューションおよびソフトウェアアップデートソースから新しいバージョンのtzdataパッケージをインストールするだけで十分です。

多くのディストリビューション開発者は、すでに彼らのディストリビューション用の更新されたtzdataパッケージをリリースしています。リポジトリから定期的に更新するLinuxディストリビューションを使用している場合、ほとんどの場合、tzdataパッケージの最新バージョンがすでにシステムにインストールされています。

Ubuntuを例として使用した最近のtzdataリリースのリリース日：

2011年9月12日-tzdataソースはバージョン2011jに更新されました。

2011年9月14日-tzdataパッケージがアップストリームUbuntu（Debian Unstable）でバージョン2011jに更新されました。

2011年9月20日-tzdata 2011jパッケージがメインのUbuntuリポジトリに配信されました。

2011年9月26日-tzdataソースはバージョン2011kに更新されました。

2011年9月26日-tzdataパッケージがアップストリームUbuntu（Debian Unstable）でバージョン2011kに更新されました。

2011年10月4日-tzdata 2011kパッケージがメインのUbuntuリポジトリに到着しました。

2011年10月10日-tzdataソースがバージョン2011lに更新されました（執筆時点では、Ubuntu用のパッケージはまだありませんでした）。

オプションとして、さまざまなLinuxディストリビューションのtzdataパッケージがここにあります。

pkgs.org/download/tzdata

パッケージマネージャーを使用したLinuxディストリビューションでは、現在インストールされているtzdataパッケージのバージョンを簡単に確認できます。

Debian / Ubuntuでは、次のコマンドを使用してこれを実行できますdpkg -s tzdata | grep Version

dpkg -s tzdata | grep Version

またはapt-cache policy tzdata

Archlinuxの場合：pacman pacman -Si tzdata | grep Version

pacman -Si tzdata | grep Version

CentOS / RHELの場合： rpm -qa | grep tzdata

rpm -qa | grep tzdata

このコマンドの出力に2011h（またはそれ以降）が含まれている場合、インストールされているtzdataのバージョンは、ロシアのタイムゾーンの2011年の変更を既に考慮しています。

このコマンドの出力に2011k（またはそれ以上）が含まれている場合、tzdataのインストールされたバージョンは、ロシアだけでなくベラルーシのタイムゾーンの2011年の変更を既に考慮しています。

tzdataデータベースがシステムで更新されているかどうかを確認するには、実験的に次のことができます。

UTC形式（過去および将来、以前のDST切り替え日付の異なる側）でいくつかのテスト日付を取ります。
date systemコマンドを使用して、モスクワ、キエフ、およびミンスクでこれらのテスト日付の現地時間を計算します（システムにインストールされたtzdataデータベースのタイムゾーンに関する情報を使用）。
システムによって計算された現地時間と実際の時間を比較します。

たとえば、これを行うスクリプトをスケッチしました： pastebin.com/VEYt9BeN

（Linuxでテスト済み、他の* nixシステムで動作するかどうかわかりません）

5つのテスト日付をチェックします。

2010-10-01 15:00 UTC

2. 2010-11-01 15:00 UTC

3. 2011-10-01 15:00 UTC

4. 2011-11-01 15:00 UTC

5. 2012-07-01 15:00 UTC

モスクワの現地時間では次のようになります。

2010-10-01 19:00 MSD（UTC + 04）

2010-11-01 18:00 MSK（UTC + 03）

3. 2011-10-01 19:00 MSK（UTC + 04）

4. 2011-11-01 19:00 MSK（UTC + 04）

5. 2012-07-01 19:00 MSK（UTC + 04）

カリーニングラード、キエフ、ミンスクの現地時間では、次のようになります。

2010-10-01 18:00 EEST（UTC + 03）

2010-11-01 17:00 EET（UTC + 02）

3. 2011-10-01 18:00 FET（UTC + 03）

4. 2011-11-01 18:00 FET（UTC + 03）

5. 2012-07-01 18:00 FET（UTC + 03）

システムでこれらの都市の現地時間を計算した結果が異なる場合、これらの地域のtzdata情報は更新されていません。

aig 氏：FreeBSDでは、ポートからtzdataを更新できます：

#cd /usr/ports/misc/zoneinfo

#sudo make install clean

#sudo tzsetup

そして、ゾーンを再度設定します。

Mac OS Xでは、tzdataの現在インストールされているバージョンを+ VERSIONファイルで表示できます。

cat /usr/share/zoneinfo/+VERSION

Mac OS X Lion 10.7.2システムアップデートでは、tzdataパッケージがバージョン2011hに更新されました。

つまり、ロシアのタイムゾーンに関する情報は既に更新されていますが、ベラルーシのタイムゾーンに関する情報はまだ利用できません（これにはtzdata 2011kの最小バージョンが必要です）

使用しているUnixシステムのベンダーが、対応するTZIのバイナリパッケージの更新をリリースしない場合は、適切な変更を手動で行う必要があります。たとえば、最新バージョンのソースからzic （Zone Info Compiler）を使用してtzdataを自分でコンパイルするか、既に更新されたシステムから既製のコンパイル済みzoneinfoファイルをコピーします。

* nixシステムでのtzdataの更新に関する追加情報は、たとえば次の場所にあります。

www.linux.org.ru/wiki/en/時間の非翻訳_2011

www.opennet.ru/tips/2630_linux_timezone_time.shtml

www.itpad.ru/?p=2257

シスコネットワーク機器

シスコ機器のタイムゾーンの現在の構成を確認します。

7606#sh run |i clock timezone

clock timezone MSK 3

コマンド出力では、ローカルタイムに指定されているタイムゾーン（この場合はMSK）と、UTCに対する相対的なシフト（この場合はUTC + 3）が有効であることがわかります。

次に、地域の正しいタイムゾーンを設定し、季節ごとの時間の転送をキャンセルします。

Cisco IOS（7206、7600、GSR、ITP7200、ITP7200、ITP7600、AS5xxx、RPM-XF）、IOS XR（ASR9k）、IOS XE（ASR1k）

コマンドを実行します。

no clock summer-time

clock timezone MSK 4

最初のコマンドは、季節のクロック転送を無効にします（特に、モスクワのタイムゾーンの場合、「clock summer-time MSK recurring last Sun Mar 2:00 Last Sun Oct 3:00」という行を構成から削除します）。

2番目のコマンドは、現在のタイムゾーン（この場合はMSK）とUTCに対する現在の時間オフセット（この場合はUTC + 4）を設定します。

他の地域では、MSKの代わりにタイムゾーンを指定する必要があります（たとえば、ノボシビルスクの場合はNSK、ウラジオストクの場合はVLAD）。ここに、現在のタイムゾーン設定が表示されたときと同じゾーンを示します（上記を参照）。

Cisco CatOS（Catalyst 6500）

コマンドを実行します。

set summertime disable

set timezone MSK 4

最初のコマンドは、季節の時計の転送を無効にします。

2番目のコマンドは、現在のタイムゾーン（この場合はMSK）とUTCに対する現在の時間オフセット（この場合はUTC + 4）を設定します。

他の地域では、MSKの代わりにタイムゾーンを指定する必要があります（たとえば、ノボシビルスクの場合はNSK、ウラジオストクの場合はVLAD）。ここに、現在のタイムゾーン設定が表示されたときと同じゾーンを示します（上記を参照）。

Cisco IOSでの時間設定の詳細については、こちらをご覧ください。

galushka.com/nastroyka-vremeni-na-cisco-otmenyaem-perehod-na-zimnee-letnee-vremya

モバイルOS

Android

Androidでは、他の多くのLinuxベースのシステムと同様に、tzdataベースは世界のタイムゾーンに関する情報を格納するために使用されます。 Android OSファイルシステム上のtzdataパッケージファイルは、パス/system/usr/share/zoneinfo/

ます。 tzdataのバージョンは、 zoneinfo.version

ファイルで確認できます。

Androidでのtzdataの更新は通常、ファームウェア全体の更新で発生します。現時点では、Androidデバイスでtzdataを更新する状況は悲しいです。 Android 2.3.6（Nexus One、Nexus Sデバイス）の最新バージョンでも、tzdataの更新は必要ありません。

（より完全な統計を収集するには、コメントに以下を指定してください：a）Androidデバイスのモデル、b）Androidのバージョン、c）tzdataのバージョン）。

Androidデバイスでの自己更新tzdata（zoneinfo）について（ルート化！）ここで見つけることができます：

androidforums.com/lg-optimus-one-p500/425466-time-zone-files-zoneinfo-tzdata.html

crazy-coder.livejournal.com/26142.html

habrahabr.ru/blogs/android/130808

forum.xda-developers.com/showpost.php?p=18370053&postcount=2

tzdataをバージョン2011kに更新するためのアプリケーションは、Androidマーケットにあります。

https://market.android.com/details?id=com.force.timezonefixer

マエモ/ meeego

ここでは、本格的なGNU / Linuxディストリビューションと同様に、tzdataが使用されます。

報告されたホールマン：

Maemo5（Fremantle）、Nokia N900-tzdataは更新されていません。

Maemo6（MeeGo 1.2 Harmattan）、Nokia N9 / N950-tzdataが更新されました

busyboxを備えたデバイスの場合、date -dコマンド12221931.30 +％sを使用して、結果を1324567890と比較する必要があります

Apple iOS（iPhone / iPad）

Apple iOSは、タイムゾーンデータベースとしてtzdataも使用します。 MacOS Xのように、現在インストールされているtzdataのバージョンは、ファイル/usr/share/zoneinfo/+VERSION

ます。

iPhone / iPadの所有者は、iOSのどのバージョンがtzdataのどのバージョンであるかについてのコメントで退会できます。 iOS 5が最近リリースされたことを考えると、2011年10月に、tzdataがかなり最新のバージョンであることを期待しています。

iOSでのtzdata（zoneinfo）の自動更新（JailBreakが必要）については、こちらをご覧ください。

habrahabr.ru/blogs/iphone/130432

ブラックベリーOS

RIM（Research In Motion）は、BlackBerryのタイムゾーンアップデート（ KB28317-2011年9月DSTアップデート）をリリースしました。

このパッチは、ロシアの9つのタイムゾーンのうち7つのみを更新します。また、BlackBerryソフトウェアは、原則として、オムスク時間（アジア/オムスクUTC + 7）およびカリーニングラード時間（ヨーロッパ/カリーニングラードUTC + 3）タイムゾーンをサポートしていないため、これらのゾーンの更新もありません。ベラルーシのタイムゾーン（ヨーロッパ/ミンスクUTC + 3）についても更新はありません。この意味で、RIMは世界中の異なるタイムゾーンに住んでいる顧客を無視しています。

企業BES（BlackBerry Enterprise Server）がある場合、このサーバーの管理者はこのサーバーに更新プログラムをインストールする必要があります。これを行うには：

1.タイムゾーンの更新は、BESがインストールされているサーバーOSにインストールする必要があります。

2.タイムゾーンの更新は、BESが統合されている企業のメールサーバーにインストールする必要があります。

3. RIMからBlackBerry Enterprise Server自体にパッチを適用する必要があります（BESの更新は、基本的にBESのSQLデータベースを修正するSQLスクリプトを使用することから成ります）。

BES接続を使用するBlackBerryスマートフォンのすべての企業ユーザーは、BESを使用して既にBlackBerryデバイスで対応するタイムゾーン更新を自動的に受信します。

BlackBerryスマートフォンの個人ユーザーは、自分でタイムゾーンアップデート（KB28317）をダウンロードできます。更新プログラムをインストールするには、組み込みブラウザーを介してBlackBerryスマートフォン自体からこのリンクを開く必要があります。

Symbian、WinMobile、WP7

Symbian、WinMobile 6.x、Windows Phone 7などの一般的なモバイルOSのタイムゾーンに関する情報をどこにどのように保存するかについての情報がありません。また、この情報を更新する方法についても知りません。あなたからこれを聞いてうれしいです。誰かが知っている場合は、コメントを追加してください。

awhiler は、Windows Phone 7.5ではタイムゾーン情報が既に更新されていると述べました。

zlordは、Symbian 6.2（Nokia 6120c）がすでにロシアのタイムゾーンに関する情報を更新していると報告しました。

Nokia Symbianベースのデバイスの更新については、こちらをご覧ください。

www.nokia.ru/support/product-support/phone-software-update

MS Windows

Windowsでは、ワールドタイムゾーンに関する情報は[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]

ブランチのシステムレジストリに保存され[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]

。ロシアとベラルーシのタイムゾーンには、次のサブセクションがあります。

ロシアの場合（2011年の更新の対象）：

カリーニングラード標準時-（UTC + 03：00）カリーニングラード

ロシア標準時-（UTC + 04：00）ボルゴグラード、モスクワ、サンクトペテルブルク

エカテリンブルク標準時-（UTC + 06：00）エカテリンブルク

中央アジア標準時-（UTC + 07：00）ノボシビルスク

北アジア標準時-（UTC + 08：00）クラスノヤルスク

北アジア東部標準時-（UTC + 09：00）イルクーツク

ヤクーツク標準時-（UTC + 10:00）ヤクーツク

ウラジオストク標準時-（UTC + 11:00）ウラジオストク

マガダン標準時-（UTC + 12:00）マガダン

ベラルーシの場合（2011年の更新を除く）：

E.ヨーロッパ標準時-（UTC + 02：00）ミンスク

Microsoftは、このタイムゾーンデータベースを個別にサポートしています。それら自体が、このベースの完全性と関連性を監視します。このデータベースへの変更は、通常、Windows Updateを通じて配布されるパッチ（Windows用の更新）の形で行われます。

ロシアのタイムゾーンの2011更新プログラムを含む累積タイムゾーンパッチ（KB2570791）は、2011年8月11日にMicrosoftによってリリースされました。

support.microsoft.com/kb/2570791/en

support.microsoft.com/kb/2570791/en

Windowsのバージョン用のパッチが提供されます。

-Windows XP SP3 [x86、x64];

-Windows Server 2003 SP2 [x86、x64、Itanium];

-Windows Vista SP2 [x86、x64];

-Windows Server 2008 SP2 [x86、x64、Itanium];

-Windows 7 [x86、x64];

-Windows Server 2008 R2 [x64、Itanium];

-Windows Embedded Standard 7 [x86、x64]。

Windows 2000 Professional / Serverの場合、パッチはリリースされていません（リリースされません）。 Win2kはMicrosoftでサポートされなくなりました。

2011年8月23日以降、このパッチ（ KB2570791 ）はWindows Updateにリリースされました。

WindowsシステムがWindows Update Webサービスを介してオフラインで更新されている場合は、すでにこの更新プログラムを受け取っているはずです。 Windowsシステムが企業ネットワーク上のWSUSサーバーを通じて一元的に更新される場合、WSUS管理者は、組織内のすべてのサーバーおよびワークステーションに到着する前に、WSUSにこの更新プログラムをインストールする必要があります。

組織でWindowsの自動更新が使用されていない場合（わからない場合）、MicrosoftのWebサイトからこのパッチを個別にダウンロードし（上記の記事へのリンクを参照）、すべてのWindowsマシンに（手動で、スクリプトで、グループを通じて）インストールできますポリシーまたはSMS / SCCM経由）。

このパッチは、レジストリキー[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones]に適切な変更を加えるだけで、システムは変更されません。パッチ（ KB2570791 ）を適用した後、システムを再起動する必要はありません。

このパッチがインストールされていることを視覚的に確認するには、タイムゾーンのシステム設定を調べます。 UTCに対するタイムゾーンシフトは、以前よりも1時間長くなり（たとえば、モスクワの場合：UTC + 3で、UTC + 4になりました）、夏時間切り替えを含むチェックボックスも消えます。

パッチKB2570791（モスクワなど）をインストールした後のWin2008-R2のスクリーンショットを次に示します。

Win2008-R2でタイムゾーンを設定する

Win2003のスクリーンショットを次に示します（アニメーション：モスクワの例にパッチKB2570791をインストールする前後）。

Win2003でタイムゾーンを設定する

レガシーWindowsシステムの更新

大規模な組織で働いた経験から、組織が大きくて官僚的であるほど、移行プロセスが遅くなり、オペレーティングシステムのフリートが遅くなることがわかります。したがって、古いデスクトップの一部である大規模な組織では、Windows 2000 Professionalは引き続き正常に動作します。さらに、Win2kサーバーは、管理者が実用的な理由でOSのアップグレードを急ぐ必要のない古いサーバーの一部の場所に配置できます。彼に触れないでください！」

組織にWin2kマシンも含まれている場合は、それらのマシンのタイムゾーンを更新することを検討する必要があります（少なくともデスクトップでは）。

上記のように、Windows 2000用のKB2570791のパッチは公開されていません。

ただし、パッチKB2570791はWindowsレジストリのタイムゾーン情報のみを編集します。また、この情報をWin2kレジストリに保存する形式は、この情報をWinXPまたはWin2k3レジストリに保存する形式と同じです。したがって、純粋に技術的には、MicrosoftがWin2kを含めて、不必要な労力なしでこのパッチをリリースすることを妨げるものは何もありませんでした。ただし、Microsoftは既にWin2kのサポートを拒否しているため、原則として、費用がかからなくても更新をリリースしません。つまり、Win2kマシンを自分で更新する必要があります。

これを行うには、十分です：

-WinXPまたはWin2k3にパッチKB2570791を適用します。

-パッチを適用したシステムのレジストリからブランチ[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones]をエクスポートします。

-ロシアのタイムゾーンに関する変更のみをそこから取得します（ただし、ロシアのタイムゾーンのみを選択せずに、一般的にすべての世界のタイムゾーンに関する情報を更新することは可能です）。

-これらの変更を* .regファイルとして保存します。

-準備された* .regファイルをWin2kマシンのレジストリにインポートします（手動、ピース、スクリプト、グループポリシーまたはSMS / SCCMを使用）。

さまざまなWindowsロケール（ロシア語、英語）用にこれらの* .regファイルをいくつか準備するか、特に英語圏のWindowsに基づいて作成された* .regファイルをどこでも使用することはできません。タイムゾーン設定のロシア語システムでも、表示される一部のゾーンの名前が英語で表示されても問題ありません。

ロシアのタイムゾーンの編集を含む既製のregファイル（ロシア語および英語ロケール用）は、ここからダウンロードできます。

*英語圏のWindowsの場合：pastebin.com/FRXwDM0u

*ロシア語圏のWindowsの場合：pastebin.com/mKe3GMVU

新しいロシアのタイムゾーンに関する情報をレジストリにインポートした後、現在のタイムゾーンをシステムに再指定して、更新された情報がレジストリから再読み取りされるようにする必要があります。この地域のタイムゾーンに応じて、Win2k / XP / 2003で次のいずれかのコマンドを実行します：

カリーニングラード時間（MSK-1）のある地域の場合：

control.exe timedate.cpl,,/z Kaliningrad Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time

モスクワ時間（MSK）のある地域の場合：

control.exe timedate.cpl,,/z Russian Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time

エカテリンブルク時間（MSK + 2）のある地域の場合：

control.exe timedate.cpl,,/z Ekaterinburg Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Ekaterinburg Standard Time

オムスク時間（MSK + 3）のある地域の場合：

control.exe timedate.cpl,,/z N. Central Asia Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z N. Central Asia Standard Time

クラスノヤルスク時間のある地域（MSK + 4）：

control.exe timedate.cpl,,/z North Asia Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia Standard Time

イルクーツク時間（MSK + 5）のある地域の場合：

control.exe timedate.cpl,,/z North Asia East Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia East Standard Time

ヤクート時間のある地域（MSK + 6）：

control.exe timedate.cpl,,/z Yakutsk Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Yakutsk Standard Time

ウラジオストク時間（MSK + 7）のある地域の場合：

control.exe timedate.cpl,,/z Vladivostok Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Vladivostok Standard Time

マガダン時間のある地域（MSK + 8）：

control.exe timedate.cpl,,/z Magadan Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

したがって、ロシアのヨーロッパ地域のWin2kコンピューターでタイムゾーンを更新するためのバッチバッチファイルは次のようになります。

regedit /s TZ-update-Russia2011.reg

control.exe timedate.cpl,,/z Russian Standard Time

または：

regedit /s TZ-update-Russia2011.reg

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time

TZ-update-Russia2011.regは、ロシアのタイムゾーンが設定されたREGファイルです（上記参照）。

ドメイングループポリシーを介してこのスクリプトを配布する場合は、2番目のオプションを使用する必要があります（runDLL32.exe shell32.dllは黒です）。

Win2kは現在のタイムゾーン情報をすぐに更新するのではなく、1分ごとに更新することに注意してください。したがって、このコマンドからの変更はすぐには機能しませんが、一定の遅延（1分以内）が発生します。

WinXP（SP3未満）およびWin2k3（SP2未満）の更新に関しては、Microsoftがリリースしたパッチもおそらく機能しません。したがって、何らかの理由で最後のサービスパックに更新したくない場合は、レジストリに変更をインポートしてロシアのタイムゾーンも更新する必要があります（Win2kと同様）。

さまざまな地域のWindowsでのタイムゾーンの再構成の機能

チャムツカ、カムチャツカ

マイクロソフトの開発者は、カムチャツカでは夏時間がないと長い間信じていました（実際には、ロシア/ソ連のように、夏時間は1981年から2009年まで、2010年3月末に適用されました）このカムチャッカタイムゾーンは存在しなくなりました）。：彼らは、フィジー（夏時間が本当になかった場合）がDSTカムチャツカの不在についてのこれらの偽の引数の1つのタイムゾーンに入れた

（UTC + 12：00） -フィジー標準時ザ・の、ペトロパブロフスク・カムチャツキー、フィジー[なしDST]

したがって、タイムゾーンの設定でカムチャッカ時間（チュコトカ、カムチャッカ）を使用した地域のWindowsユーザーの場合、夏時間のチェックマークがオフになっているだけでなく、通常、カムチャッカベルトのこのチェックボックスがありませんでした。そして、タイムゾーンの通常の標準設定では、そこで夏時間をオンにすることは不可能でした。このバグ

の修正（KB970653）は2009年8月にのみリリースされました。

この修正では、カムチャッカはフィジー標準時間帯から削除され、別のカムチャッカ標準時間帯が作成されました。このパッチの後、2つの別々のゾーンがWindowsに現れました：

フィジー標準時-（UTC + 12：00）フィジー[DSTなし]

カムチャッカ標準時-（UTC + 12：00）ペトロパブロフスク-カムチャツキー[DST付き]

Windowsにはチュコトカとカムチャツカの通常のタイムゾーン（夏季サポート付き）が非常に長い間存在しなかったため、これらの地域のユーザーと管理者は自分で出なければなりませんでした。パッチKB970653の前の最も便利な解決策は、システムレジストリのフィジー標準タイムゾーンの情報を編集して、このゾーンに夏時間のチェックマークを追加し、有効にすることでした。

2010年3月末、カムチャッカ時間帯はロシアで廃止され、そのすべての地域はマガダン時間帯に移動しました。しかし、それでも、この問題は解決されませんでした（以下を参照）。

マガダン

また、マイクロソフトの開発者は長い間、マガダンでは夏時間がないことを信じていました（実際にはロシア/ソビエト連邦では、夏時間は1981年から2011年まで使用されていました）。 DSTマガダンの不在についてのこれらの誤った考慮事項から、彼らはソロモン諸島およびニューカレドニアと同じタイムゾーンに配置しました（実際には夏時間はありませんでした）：

中央太平洋標準時-（UTC + 11：00）ソロモン諸島マガダンワ、ニューカレドニア[DSTなし]

したがって、マガダン時間を使用した地域のWindowsユーザー（最初はマガダン地域とヤクーチアの東部地域のみであり、2010年3月末からチュコトカとカムチャツカも参加しました）は、夏時間のチェックマークのタイムゾーンの設定で削除され、一般的にマガダンベルトのこのチェックボックス自体はありませんでした。そして、タイムゾーンの通常の標準設定では、そこで夏時間をオンにすることは不可能でした。このバグ

の修正（KB2443685）は2010年12月にのみリリースされました。

この修正では、マガダンが中部太平洋標準時間帯から削除され、別のマガダン標準時間帯が作成されました。このWindowsのパッチの後、2つの別々のベルトが現れました。

中部太平洋標準時-（UTC + 11:00）ソロモン諸島、ニューカレドニア[DSTなし]

マガダン標準時-（UTC + 11:00）マガダン[DST付き]

Windowsの時間が非常に長いためマガダンには通常のタイムゾーンがありません（サマータイムサポート付き）。マガダンの時間がある地域のユーザーと管理者は自分で出なければなりませんでした。パッチKB2443685より前の最も便利な解決策は、システムレジストリの中央太平洋標準時情報を編集して、このゾーンに夏時間を追加し、有効にすることでした。

KB2443685パッチがリリースされた後に新しいWindowsインストールがインストールされた場合、管理者は通常、このパッチを適用した後、開発者向けに正しい修正済みのタイムゾーンを選択しました：マガダン標準時-（UTC + 11：00）マガダン[with DST]。

しかし、パッチKB2443685を適用した後でも、2010年12月より前にインストールされたほとんどのWindowsシステムでは、調整されたマガダンタイムゾーンがタイムゾーンのリストに表示されました：マガダン標準時-（UTC + 11：00）マガダン[with DST]、but here自己修正され、DSTが追加された現在の中央太平洋標準時が現在のものとして選択されています。

したがって、マガダン時間のある地域（チュコトカ、カムチャッカ、マガダン地域、北クリル諸島、ヤクーチアの東部地域）にあるすべてのWindowsコンピューターでロシアのタイムゾーン（KB2570791）を次に修正する場合、現在のタイムゾーンを確認する必要がありますマガダン時間が選択されました。それ以外の場合、このパッチを使用すると、Magadanのタイムゾーンが修正されますが、これだけでは効果がありません。システムでは、完全に異なるタイムゾーンが現在のタイムゾーンとして選択されます。

これは、パッチKB2570791（パッチKB2443685が既にインストールされている場合）を適用する前と後の両方で実行できます。これは、手動で実行するか、スクリプトまたはSMS / SCCMを使用して自動化できます。自動化のために、次のコンソールコマンドを使用できます。

Win2kのマガダンのタイムゾーンでは、コンソールコマンドを選択することができます

control.exe timedate.cpl,,/z Magadan Standard Time

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

：WinXPの/ 2003マガダンのタイムゾーンでは、コンソールコマンドを選択することができます

tzchange /c "Magadan Standard Time"

Win2kのと同様に、または：

control.exe timedate.cpl,,/z Magadan Standard Time

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

win7の/ 2008 R2マガダンの時間帯では、コンソールコマンドを選択することができます：

tzutil /s "Magadan Standard Time"

WinVista / 2008年に、私は現在のタイムゾーンを変更するための組み込みのコンソールユーティリティは見つかりませんでしたが、Win7またはWin2008-R2から借用したtzutil.exeユーティリティがここで機能します。

サハリン州とヤクーチア

これら2つの地域（ロシア連邦の構成事業体）は、完全に同じタイムゾーン内にあるわけではありません。地区の一部は1つのタイムゾーンにあり、一部は別のタイムゾーンにあります。

したがって、サハリン地域には2つのタイムゾーンがあります。北クリル地域では-マガダン時間（UTC + 12、MSK + 8）。サハリン州の残りの地域-ウラジオストク時間（UTC + 11、MSK + 7）。

ヤクーチアでは、一般に3つのタイムゾーンがあります。ヤクート時間（UTC + 10、MSK + 6）、ウラジオストク時間（UTC + 11、MSK + 7）、マガダン時間（UTC + 12、MSK + 8）。これらの時間帯によるヤクーチアの地域の正確な分布については、政府決議第725号を参照してください。

したがって、サハリン州内のタイムゾーン間の境界は以前に確立されています。しかし、ヤクーチア内では、この政府決定第725号によってタイムゾーンの境界が変更されました。

ヤクーチアのタイムゾーン

これらの地域に突然ITインフラストラクチャがある場合は、タイムゾーンを選択するときに注意してください。

サマラ、イジェフスク（ウドムルト

共和国）ロシアのこれらの地域のWindowsには、長い間、個別のタイムゾーンがまったくありませんでした。したがって、これらの地域のWindowsユーザー/管理者は、同様の時間計算が使用される時間設定で回避策を探し、隣接する州（通常はアルメニア/エレバンまたはアゼルバイジャン/バクー）のタイムゾーンを選択する必要がありました。 2010年3月末に、サマラ時間（MSK + 1）のタイムゾーンが完全に廃止され、サマラ地域とウドムルティアがモスクワ時間に追加されました。そして今、良い意味で、これらの地域のすべてのWindowsシステムでは、モスクワの時間が選択されるべきです。

しかし、外国のタイムゾーンを選択した古い倒錯の残骸は、一部のWindowsマシンの設定のどこかに保存される可能性があります。したがって、念のため、すべての場所をチェックして、必要に応じてモスクワ時間に置き換えてください。手動でも可能ですが、コンソールコマンドを使用してモスクワのタイムゾーンを選択して、スクリプトと自動化を再度実行できます：

xp、2003：tzchange /c "Russian Standard Time"

2k、xp、2003：

control.exe timedate.cpl,,/z Russian Standard Time

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time

WinVista / 2008：tzutil /s "Russian Standard Time"

（copy tzutil.exe from Win7 / 2008-R2）

Win7 / 2008- R2：tzutil /s "Russian Standard Time"

カリーニングラード

Windowsのカリーニングラード地域には別のタイムゾーンがなかったため、カリーニングラードのタイムゾーンの設定では、通常、ローカル時間に対応するヨーロッパのタイムゾーンを選択しました。たとえば、

FLE標準時間-（UTC + 02：00）ビリニュス、キエフ、リガ、ソフィア、タリン、ヘルシンキ

E.ヨーロッパ標準時間-（UTC + 02：00）ミンスク

GTB標準時間-（UTC + 02：00）

カリーニングラードのWindowsのKB2570791アップデートで、独自のタイムゾーンを追加しました（ DSTなし）：

カリーニングラード標準時-（UTC + 03：00）カリーニングラード

しかし、このパッチを適用すると、カリーニングラードのこの新しいタイムゾーンはタイムゾーンのリストに追加されるだけで、現在のタイムゾーンとして自動的に選択されることはありません。そのため、カリーニングラードのWindowsコンピューターにパッチKB2570791を適用した後（必然的に！）、タイムゾーン設定でシステムのカリーニングラード時間を追加で選択する必要があります。これを手動で行うことも、コンソールコマンドを使用してスクリプトを作成し、自動化してカリーニングラードタイムゾーンを選択することもできます：

xp、2003：tzchange /c "Kaliningrad Standard Time"

2k、xp、2003：

control.exe timedate.cpl,,/z Kaliningrad Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time

WinVista / 2008：tzutil /s "Kaliningrad Standard Time"

（Win7 / 2008-R2からのtzutil.exeコピー）

Win7 / 2008-R2：tzutil /s "Kaliningrad Standard Time"

ベラルーシベラルーシ

のタイムゾーンの変更に関しては、Microsoftはこれを認識していますが、ベラルーシの時間に対応するWindowsパッチをリリースしません。どうやら、彼らはあまりにも怠laすぎて、累積的な更新の予定されたスケジュールに負担をかけずに抜け出すことができません。彼らは、2011年12月にリリースされるWindowsタイムゾーンの次回の累積更新に、ウクライナ、ベラルーシ、およびアルメニアのタイムゾーンの変更を含める予定です。しかし、その時点でアルメニアとウクライナでこれに関する立法上の決定があるかどうかはまだ明確ではありません。それまで、Microsoftはベラルーシ~~のマグロのサーモン~~からWindowsユーザーに対して、このような松葉杖を手動で使用することを提案しています

。1）パッチKB2570791をインストールします、ロシアのタイムゾーンを変更します。

2）ベラルーシのユーザーの場合、タイムゾーンとして選択します：（UTC +3：00）Kaliningrad

そして、2011年12月の次の累積WinUpdateタイムゾーンの後、最終的にベラルーシのタイムゾーンを修正します（そしておそらくウクライナとアルメニアでも）、ベラルーシのすべてのユーザーにこの更新プログラムをインストールしてから、国のシステム時間設定でタイムゾーンをネイティブ（既に使用されている）に手動で戻すように提供しています。

これは私の発明ではありません。これについてはMicrosoftの公式記事に記載されています。support.microsoft.com /

kb / 2625508 / en

support.microsoft.com/kb/2625508/en

ベラルーシのカリーニングラードの時間設定（パッチKB2570791の後）は手動で行うことができますが、コンソールコマンドを使用してカリーニングラードのタイムゾーンを選択して、スクリプトと自動化を再度行うことができます：

xp、2003：tzchange /c "Kaliningrad Standard Time"

2k、xp、2003：

control.exe timedate.cpl,,/z Kaliningrad Standard Time

または

RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time

WinVista / 2008：tzutil /s "Kaliningrad Standard Time"

（Win7 / 2008-R2からのtzutil.exeコピー）

Win7 / 2008-R2：tzutil /s "Kaliningrad Standard Time"

MS Active Diectoryドメインコントローラーのタイムゾーンを更新する

ドメインコントローラのサーバーおよび他のWindowsマシンにパッチKB2570791をインストールするだけです。ドメインコントローラーに違いがないように、この更新プログラムをすべてのADフォレストコントローラーに1日でインストールすることをお勧めします。

コントローラーの更新には、1つのバグがあります。組織にログインの制限時間（ログオン時間）があるユーザーに対するある種の偏執的なセキュリティ要件があり、それに応じてユーザーのlogonHours属性が設定されている場合、ドメインコントローラーにKB2570791更新プログラムをインストールするとすぐに、すべてのユーザーがログイン範囲を許可しますシステムは1時間シフトします。この問題は、10月30日以降ではなく、コントローラーパッチの直後に発生します。

たとえば、ユーザーのログイン許可時間が9〜18時間の範囲に設定されている場合、ドメインコントローラーのパッチの後、ユーザーは10〜19時間のログインが許可されます。つまりそのような制限のあるユーザーは、翌朝、管理者がこの制限を解除するか午前10時までログインできなくなります。

さらに、この許可されたログオンの間隔は、パッチKB2570791がインストールされたコントローラーでのみ変更されます。このパッチを一部のコントローラーにインストールし、まだ他のコントローラーにはインストールしていない場合、一部のユーザーは（パッチを当てていないコントローラーにログオンしたため）ログインできたが、他のユーザーはログインできなかったことが判明する場合があります既にパッチが適用されたコントローラーにログオンしたとき）、最初はログオン時と同じ権限を持っていました。これにより、問題の診断が困難になる場合があります。

そのため、ドメインコントローラにパッチKB2570791をインストールする前に、システムのログオン時間制限があるドメイン内のユーザー数を評価する必要があります。これを行うには、logonHoursを持つユーザーのリストをファイルにアップロードして確認します。属性logonHoursをアップロードする例PowerShellスクリプト-ユーザー：pastebin.com/0Ucu7MKi

いるユーザーがいない場合はすべてがOKである、そして、すべてのコントローラは、痛みのないパッチすることができます。 ADにそのようなユーザーがいる場合、それらの問題は何らかの形で解決する必要があります。 2つの明らかなオプションがあります

。1）ログイン時間に関するこれらの制限を放棄し、すべてのユーザーがlogonHours属性に入力して、ログイン時間に制限がないようにします（スクリプトを使用できます）。

2）すべてのユーザーに対してすべてのログオン時間の範囲を1時間前にシフトするスクリプトを作成し、すべてのドメインコントローラーのパッチの直後にこのスクリプトを実行します。

MS Exchangeサーバーのタイムゾーンの更新

Exchangeメールシステムにタイムゾーンに関する情報が保存されているため、何らかの混乱が起こっています。

このタイムゾーンの変更で最も予想されるExchangeメールシステムの問題は、異なるカレンダーのカレンダーイベントが同期していないことです。取締役会のビジネスミーティングが10時間予定されているが、参加者の1人が9時間でカレンダーを見て（そして1時間早く到着した）、もう1人が10時間でカレンダーを見て（そして時間通りに到着した）、3人目が彼女を見て11時のカレンダーで（そして1時間遅れでした）。

たとえば、カレンダーに追加された1回限りのイベントおよび定期的に発生するイベント（例：年次）は、さまざまな形式でExchangeメールデータベースに保存されます：1つの場合、タイムゾーンは指定された時間と共に保存され、他の場合には保存されません。そして、タイムゾーンを変更するとき、それは重要です。

MS Office OutlookとOWA（Outlook Web Access）を介して同じカレンダーにアクセスする場合でも、異なるデータを表示できます。 OWAには、タイムゾーン情報に関する何らかの見通しがあります。

さらに、他の要因が異なるカレンダーのカレンダーイベントの正しい表示に影響する場合

があります。-送信者と受信者のコンピューターにあるOutlookのバージョン。

-メールボックスは、メールデータベースのサーバーまたはPSTファイルにローカルに保存されます。

-送信側と受信側の両方のコンピューターにWindowsシステムがパッチされているかどうか。

-送信者と受信者が同じタイムゾーンにいるかどうか。

-パッチがインストールされる前、またはカレンダーイベントが作成された後。

-送信者ボックスと受信者ボックスが配置されているExchangeメールボックスサーバーにWindowsシステムがパッチされているかどうか。

など

さらに、ほとんどの場合、カレンダーイベントの同期に問題はないかもしれませんが、上記の要因のいくつかの組み合わせにより、異なるカレンダーの一部のイベントも時間内に分散する可能性があります。

たとえば、更新プログラムKB2570791がインストールされていないWindowsマシンのユーザーが、たとえば2011年11月1日（または2011年10月30日の後の日）の10:00から11:00に予定表を予約し、これに招待状を送信する場合既にWindowsマシン上にパッチKB2570791を持っているユーザーに会うと、送信者と受信者はカレンダーの異なる時間にこのイベントを見ることになります。送信者は10:00から11:00まで、受信者は11:00から12:00までなので、この会議に遅れる危険があります。

逆に、パッチを適用したマシンで10月30日以降の日付の予定を作成し、パッチを適用していないマシンでユーザーに招待状を送信すると、1時間のタイムシフトはすでに反対方向になります。ここで最も不愉快なことは、カレンダーイベントの送信者と受信者が異なる組織のものである可能性があることです。したがって、両方のマシンにパッチをインストールするためには、技術的な能力がまったくない可能性があります（これらのユーザーのどちらか一方のコンピューターによって制御される場合があります）。

Microsoftによると、タイムゾーンに関する情報を保存する問題は、Exchange 2010で多かれ少なかれ解消されましたが、Exchange 2003とExchange 2007を使用している場合、カレンダーイベントの同期に関する問題はかなり可能です。さらに、パッチKB2570791をインストールした後問題はクライアントワークステーションとExchangeサーバーには表示されない可能性がありますが、2011年10月30日以降、パッチが適用されていないWindowsシステムは1時間前に移動され、カレンダーでこのような問題が発生する可能性があります。

マイクロソフトのサポートは、このような問題からExchangeメールシステムを事前に保護する方法について明確な回答を提供していませんが、推奨事項は次のとおりです

。1. すべてのWindowsクライアントマシンにパッチKB2570791をインストールします。

2.パッチKB2570791を組織内のすべてのExchangeサーバーおよびすべてのドメインコントローラーにインストールします。

3. Exchange 2007（SP3）サーバーがある場合は、それらに更新プログラムのロールアップ5をインストールします。

4.次に、ユーザー間のカレンダーイベントの問題を観察して特定します。

5.ユーザーがカレンダーのカレンダーイベントのシフトについて苦情を申し立てる場合：

a）サーバー側で、Exchangeカレンダー更新ツールを実行して、特定の問題のあるユーザーの特定のサーバーのカレンダーを修正します。

b）クライアント側で、Outlookタイムゾーンデータ更新ツールを起動して、Outlook側のカレンダーを修正します。

MS Sharepointサーバーのタイムゾーンの更新

MS SharePointを使用するサーバーでは、まずWindows更新KB2570791をインストールし、次にSharePoint自体の更新をインストールする必要があります。

- MS SharePoint 2007の更新（SharePoint Serveces 3.0） ;

- MS SharePoint 2010のための更新。

また、Microsoft製品のタイムゾーンの更新に関する情報もこちらでご覧ください：

support.microsoft.com/gp/cp_dst/en

support.microsoft.com/gp/cp_dst/en

OSおよびソフトウェアのタイムゾーン情報を更新する必要があるのはいつですか？

正式には、ロシアとベラルーシでは、タイムゾーンの時間の新しい計算が既に実施されています（採用されている法律を参照）。したがって、これに関連するすべてのOS /ソフトウェアの更新は実行可能であり、実行する必要があります。さらに、タイムゾーンの更新に関するすべての作業は、2011年10月30日より前に行う必要があります。10月30日（10月の最終日曜日）に新しいタイムゾーンに関する情報が更新されていないシステムは、移行が既に行われていることを知らないため、夏時間から標準時間に戻ろうとしますキャンセル）、これにより問題が発生する可能性があります（少なくとも現地時間の誤った表示に関する問題）。

数週間前までに残りました。したがって、この作業を長い箱に入れないでください。もう一度、ITファーム（サーバー、アプリケーション、サービスなど）を注意深く確認し、可能な限りタイムゾーンに関する情報を更新する作業を計画および実行します。

BC（ビジネスクリティカル）およびMC（ミッションクリティカル）のレベルでは、これらの問題が会社のシステムに影響を与えないことを期待することしかできません。たとえば、ビジネスが課金システムに関連付けられている場合、または現地時間に関連付けられている正確な財務計算（現在および過去の両方）に関連付けられている場合、時間の経過とともに発生する問題により、特定のビジネス上の損失が生じる可能性があります。

Outlookの一部のカレンダーイベントの1時間ごとのシフトなど、OP（Office Productivity）レベルの重要ではないシステムへの影響は、通常、ビジネスの観点からは重要ではありません。

もちろん、パニックはそれだけの価値はありませんが、一部のITシステムのタイムゾーンの変更に関連する問題が発生する可能性が高いという事実に備えてください。パッチ/修正を適用した直後でない場合は、2011年10月30日から確実に。

ロシアのタイムゾーンの変更に関する別のトピックもご覧ください

。MSDタイムゾーンをMSKに移行-ローカルスケールの新しいY2K

^{: <ya.roman.tik {t} yandex.ru>

«Creative Commons Attribution 3.0 Unported» (CC BY 3.0). , .}

ロシア、ベラルーシ、ウクライナのタイムゾーンの変更

内容