Change of time zones in Russia, Belarus and Ukraine

As you have probably already heard, in the fall of 2011 several states decided to change the order in which time is calculated on their territory, as well as to cancel the seasonal transition to summer time.
In the list of these states: Russia, Belarus, Ukraine, partially recognized states: Abkhazia and South Ossetia, as well as the unrecognized state of Transnistria . Those. in all time zones of these countries, there will now be a fixed shift relative to UTC all year round, with no additional seasonal shifts.
( Note: Ukraine first made the decision to switch to UTC + 3 time without summer time, but then canceled the earlier decision and so far returned to the previous time-keeping order with seasonal clock transfers. Details below.)

In this article I will describe the essence of the accepted changes in time zones and describe the technical side of the issue regarding IT systems (corporate infrastructure, servers, workstations, services, applications, etc.). I will try to answer a number of basic questions that arise in connection with these changes:
- What IT systems can affect the change in time zones?
- What problems can this cause?
- How to prepare for this, to avoid problems if possible?

I guess many system / application administrators, as well as some application / service developers, will find it helpful to read this material. And then I invite all interested to discuss and supplement this information in the comments.

Content

So the "summer" or "winter" time canceled?
Legislative basis for changing the time frame
What time will be in the new time zones?
List of Russian time zones
The composition of the territories of the Russian Federation, forming the time zones of the Russian Federation
Time Zones of Ukraine and Belarus
And what about summer time in other countries?
The expediency of using summer time
What could be the problem due to changing time zones?
What to do?
And what if we have the exact time synchronized with NTP or GPS?
Updating time zone information (TZI, Time Zone Information) in various operating systems
Unix systems and unix-like operating systems
Cisco networking equipment
Mobile OS
MS Windows
Upgrading Outdated Windows Systems
Features of reconfiguring time zones in Windows for different regions
Chukotka, Kamchatka
Magadan
Sakhalin Region and Yakutia
Samara, Izhevsk (Udmurtia)
Kaliningrad
Belorussia
Update time zones on MS Active Diectory domain controllers
Update time zones on MS Exchange servers
Update time zones on MS Sharepoint servers
When do I need to update information about time zones in the OS and software?
')

So the "summer" or "winter" time canceled?

Some journalists in the news notes interpreted these changes in the time zones in Russia and Belarus as "the abolition of winter time." From the philistine point of view, everything looks exactly like that, because The transition to summertime in the spring in these countries was, and there will be no reverse transition. Therefore, it seems that time is now always “summer”, and there will no longer be “winter” time.

But formally, no "winter time" simply does not exist. There is a standard time, plus in some countries a daylight saving time (DST, daylight saving time ) is adopted, when in the summer period (usually from the end of March to the end of October) one more hour is added to the standard local time.
So now in all the time zones of Russia and Belarus two events occur:
1) One more hour is added to the standard time on an ongoing basis.
2) Seasonal clock transfers are canceled (i.e., daylight saving time is canceled).

Thus, on the night of October 29-30, 2011, when almost all European countries will move the clock one hour back to return their local time from summer to standard, in Russia and Belarus the clock will not be transferred, because The new accepted time coincides with the previously used summer time in these territories. Well, in the future in these countries the clock for daylight saving time and back will not be transferred (as long as these decisions are not canceled by law).

Legislative basis for changing the time frame

In Russia, these changes were introduced * by the Decree of the Government of the Russian Federation of August 31, 2011 No. 725 "On the composition of the territories forming each time zone and the procedure for calculating time in time zones, as well as on recognizing as invalid certain resolutions of the Government of the Russian Federation" ( published and entered into force on September 6, 2011).

In Belarus, these changes were introduced by the Resolution of the Council of Ministers of the Republic of Belarus of September 15, 2011 No. 1229 “On the calculation of time on the territory of the Republic of Belarus” ( PDF ).

In Ukraine:
September 20, 2011 - The Verkhovna Rada of Ukraine adopted Resolution No. 3755-VI “On Changing the Time Calculation Procedure on the Territory of Ukraine” [ DOC ] (signed by the Chairman of the Verkhovna Rada of Ukraine on September 29, 2011). This resolution established the time of UTC + 3 on the territory of all Ukraine and the abolition of seasonal clock transfers, i.e. saving time UTC + 3 all year.

October 18, 2011 - the Verkhovna Rada of Ukraine adopted a new Resolution No. 3914-VI “On the recognition of the Resolution of the Verkhovna Rada of Ukraine" On the change of the time calculation on the territory of Ukraine "[ DOC ] (signed by the Chairman of the Verkhovna Rada of Ukraine on October 19, 2011) which recognizes the previous Resolution of the Verkhovna Rada No. 3755-VI, adopted on September 20, 2011 and already in force, to become invalid. Accordingly, after the entry into force of this Decree of BP No. 3914-VI, the former procedure for calculating local time in Ukraine returned: standard time (in winter) UTC + 2 and summer time UTC + 3.

After October 30, 2011, when Ukraine returns from the summer time (UTC + 3) to its standard time (UTC + 2), the Cabinet of Ministers of Ukraine should send a bill to the Verkhovna Rada of Ukraine, which will cancel the summer time for Ukraine time. If this resolution is adopted, Ukraine at the end of March 2012 will no longer switch to summer time, and throughout the whole territory of Ukraine there will be a fixed time of year round UTC + 2 (without DST).

In Armenia , judging by reports in the press , a draft law on the abolition of seasonal transitions to summer time and back is being prepared, but has not yet been legislatively adopted by the parliament (National Assembly) of Armenia. It is already known that on October 30, 2011, Armenia sets the clock back an hour from summer time (UTC + 5) to standard time (UTC + 4). But it is expected that by March 2012, the law canceling seasonal remittance of clocks in Armenia will be finally approved and come into force. If this happens, then at the end of March 2012, Armenia will no longer switch to summer time, and there will be a fixed time of UTC + 4 all year round (without DST).

I don’t have links to official legislative acts of Abkhazia and South Ossetia , establishing the change of time zones in 2011. As far as I know, such documents do not exist at all. Just in these countries during the declaration of independence, local time is set to Moscow time (for political reasons). Accordingly, due to the change in Moscow time in 2011 and the refusal to switch to summer time in Russia, in Abkhazia and South Ossetia, time also changes by analogy with Moscow. Thus, now in Abkhazia and South Ossetia, local time will coincide with local time in the whole of Georgia (UTC + 4) not only in summer, but generally year-round.

In the Pridnestrovskaia Moldavskaia Respublika, these changes were introduced by Decree of the President of the Transdniestrian Moldavian Republic of October 10, 2011 No. 770 “On the abolition of the transition to the seasonal time in the territory of the Pridnestrovskaia Moldavskaia Respublika” (effective from October 18, 2011). Moreover, the rest of Moldova does not change the order in which time is calculated on its territory, therefore on October 30, 2011 Moldova will switch back to its standard (winter) time.

* Note : in some articles on the Internet on the topic of changing time zones in Russia in 2011, it is erroneously stated that the new procedure for calculating time in time zones of Russia, as well as the abolition of seasonal watch transfers in the territory of the Russian Federation, is established by the Federal Law of the Russian Federation “On the calculation of time” signed by the President of the Russian Federation (Dmitry A. Medvedev) in June 2011. However, in reality it is not.

Indeed, there is the Federal Law of the Russian Federation “On the calculation of time” (107- of June 3, 2011):
- adopted by the State Duma: May 20, 2011;
- approved by the Federation Council: May 25, 2011;
- signed by the President of the Russian Federation: June 3, 2011;
- published: June 6, 2011 ;
- entered into force on August 7, 2011
But only he does not establish the boundaries of the time zones of Russia, does not determine the time in each of the time zones and does not establish the abolition of the seasonal transition to summer time.
This Federal Law simply describes the general definitions and principles for calculating time (how many days a year, how often a leap year, what is a calendar day / week / month / year, when the beginning and end of the day / year, what is the time zone and local time, how information is distributed about the exact time, etc.).
The law also states that specific decisions on the division of regions of the Russian Federation into time zones, on the establishment of borders of time zones and on the calculation of time in these time zones are made by the Government of the Russian Federation. And for these purposes, it was precisely the resolution of the Government of the Russian Federation “On the composition of the territories forming each time zone, and the procedure for calculating time in time zones, as well as on the recognition of certain decrees of the Government of the Russian Federation”, which regulates these issues. And it is in the government decree that all specifics regarding the time zones of the Russian Federation are indicated:
a) The boundaries of time zones are established;
b) Set the shift of the local (local) time in each of the zones;
c) Seasonal clock transfer (DST) is canceled throughout the Russian Federation.
But for some reason, some people mistakenly decided that new time zones and the abolition of the transition to summer time in the Russian Federation were introduced in the Federal Law "On the calculation of time." And some Wikipedia editors, not understanding the situation, even in June 2011 rushed to actively correct Wikipedia articles that referred to Russian time zones, indicating there is already a new time and the lack of a transition to summer time. But in reality, there were no legal grounds for such revisions at that time. Legal grounds for such changes appeared only on September 6, 2011, when the RF Government Decree No. 725 of August 31, 2011 entered into force .

What time will be in the new time zones?

List of Russian time zones

_{Table 1 List of time zones * Russia (September 2011)}

No	Local time	UTC offset	DST	International title	International abbrev
one	Moscow time -1	UTC + 03: 00	-	Kaliningrad Time	USZ1, FET (MSK-1)
2	Moscow time	UTC + 04: 00	-	Moscow Time	MSK
3	Moscow time +2	UTC + 06: 00	-	Yekaterinburg Time	YEKT (MSK + 2)
four	Moscow time +3	UTC + 07: 00	-	Omsk time	OMST (MSK + 3)
five	Moscow time +4	UTC + 08: 00	-	Krasnoyarsk Time	KRAT (MSK + 4)
6	Moscow time +5	UTC + 09: 00	-	Irkutsk Time	IRKT (MSK + 5)
7	Moscow time +6	UTC + 10: 00	-	Yakutsk Time	YAKT (MSK + 6)
eight	Moscow time +7	UTC + 11: 00	-	Vladivostok Time	VLAT (MSK + 7)
9	Moscow time +8	UTC + 12:00	-	Magadan Time	MAGT (MSK + 8)

^{* Now in Russia they are not officially called time zones, but time zones.}

The composition of the territories of the Russian Federation, forming the time zones of the Russian Federation:

1st time zone - MSK-1 (UTC + 03: 00):
Kaliningrad region.
2nd time zone - MSK (UTC + 04: 00):
Moscow and the whole European part of Russia (for a full list of regions, see Government Decree No. 725 ).
3rd time zone - MSK + 2 (UTC + 06: 00):
The Republic of Bashkortostan, Perm Territory, Kurgan Oblast, Orenburg Oblast, Sverdlovsk Oblast, Tyumen Oblast, Chelyabinsk Oblast, Khanty-Mansi Autonomous Okrug - Yugra and Yamalo-Nenets Autonomous Okrug.
4th time zone - MSK + 3 (UTC + 07: 00):
Republic of Altai, Altai Territory, Kemerovo Region, Novosibirsk Region, Omsk Region and Tomsk Region.
5th hour zone - MSK + 4 (UTC + 08: 00):
The Republic of Tyva, the Republic of Khakassia and the Krasnoyarsk Territory.
6th hour zone - MSK + 5 (UTC + 09: 00):
Republic of Buryatia and the Irkutsk region.
7th time zone - MSK + 6 (UTC + 10: 00):
Most of the Republic of Sakha (Yakutia), including Yakutsk (for a full list of districts of Yakutia, see Government Decision No. 725 ), the Trans-Baikal Territory and the Amur Region.
8th time zone - MSK + 7 (UTC + 11: 00):
Primorsky Krai, Khabarovsk Territory, Jewish Autonomous Region, a part of the Sakha Republic (Yakutia) (Verkhoyansk, Oymyakonsky and Ust-Yansky uluses (districts)), part of the Sakhalin region (all districts except the North Kuril).
9th hour zone - MSK + 8 (UTC + 12: 00):
Kamchatka Territory, Magadan Region, Chukotka Autonomous Region, part of the Republic of Sakha (Yakutia) (Abyisky, Allaikhovsky, Verkhnekolymsky, Momsky, Nizhnekolymsky and Srednekolymsky ulus (districts)), part of the Sakhalin region (North Kurilsky district).

Time zones of Ukraine, Belarus, Abkhazia, North Ossetia and PMR

The time zone on the territory of all Belarus is one: Minsk time (UTC + 03: 00) - Further-eastern European Time (FET).
The time zone on the territory of all Ukraine is one: Kiev time (UTC + 03: 00) - Further-eastern European Time (FET). Ukraine has so far returned to the former time-keeping order: in winter, the standard Kiev time (UTC + 02: 00), in the summer - Summer Kiev time (UTC + 03: 00).
The time zone on the territory of Abkhazia and South Ossetia is Moscow (or Tbilisi) time (UTC + 04: 00) .
The time zone on the territory of the Pridnestrovian Moldavian Republic is: (UTC + 03: 00) - Further-eastern European Time (FET).

As mentioned above, all of the listed time zones (except Ukraine) without switching to summer time (without DST), i.e. The indicated shift relative to UTC will be constant in these time zones throughout the year (in the winter and in the summer in one color). For Ukraine, the rules with seasonal transitions of time are in effect, but most likely Ukraine will switch to UTC + 2 in the coming months without switching to summer time, which means at the end of October 2011 they will set the clock for the last time, and in spring 2012 and beyond this will not.

In Russia, Belarus, North Ossetia and Abkhazia, these changes in time zones have already taken effect and are already in effect.

And what about summer time in other countries?

In addition to the territories of Russia and Belarus, where only this year new time zones were established without switching to summer time, the transition to summer time in the following post-Soviet states has also been absent for several years: Georgia, Kazakhstan, Uzbekistan, Turkmenistan, Tajikistan, Kyrgyzstan. From the post-Soviet republics, the transition to summer time has so far remained only in seven states: Lithuania, Latvia, Estonia, Moldova, Azerbaijan, Ukraine, Armenia. Moreover, it is expected that Ukraine and Armenia in the fall of 2011 will move the watches for the last time, and then they will pass a law on the abolition of seasonal remittance watches on their territory and will fix the permanent effect of the current standard time throughout the year.

Abkhazia and South Ossetia (partially recognized states) also after Russia announced the cancellation of the transition to summer time in 2011, now there will be a UTC + 4 time zone all year round (without switching to summer time), i.e. as in all of Georgia and in Moscow.
In addition, there is no daylight saving time from Russia’s closest neighbors in Mongolia, China and Japan.

In general, in the world, the situation with the use of summer time is shown in this illustration:

As you can see, in most countries of the world there is no daylight saving time now. But daylight saving time is still used throughout almost all of North America and Europe. And this means that with us (Russia and Belarus) the time difference with these countries will now be non-permanent (in summer the difference is an hour less than in winter). At first it will be unusual and may cause some inconvenience, but then we will gradually get used to it (and maybe America and Europe will later give up on summer time, who knows).

The expediency of using summer time

Disputes about the feasibility of the transition to summer time are long. Initially, the time shift by an hour in the summer period was introduced with the aim of more efficient use of daylight hours and saving energy spent on lighting streets and houses in the evening. And it really gave a tangible economic gain about 50 years ago, when lighting occupied a significant share in the costs of all electricity. But in the modern world, the share of electricity consumed for lighting is already small compared to other energy costs (for industrial production, for heating, for ventilation, for air conditioning). As a result, and the savings from the transition to summer time is a penny in the total mass of energy consumption. (According to RAO UES of Russia for 2007, the switch in the country can save 4.4 billion kilowatt-hours of electricity, which is about 0.5% of the total electricity consumed in Russia.)

In addition, in tropical latitudes, the length of the day and night varies little during the year, while in polar latitudes, on the contrary, there is a polar day in summer and a polar night in winter. Because of these features, it is economically efficient to introduce the transition to summer time only in areas in the latitude band from approximately 30 ° to 55 °. Alas, most of Russia is located north of these latitudes.

Well and minuses in the transfer of arrows twice a year is also enough:
- Sbivka schedules of traffic in the days of the transfer hours;
- simple and economic losses for freight forwarders in the days of transfer of hours;
- health problems in people caused by a shift in wakefulness and sleep;
- problems in agricultural animals caused by changes in the time of milking / feeding.

Personally, I see in the transitions to summer time and back more minuses than advantages. Therefore, I consider the abolition of daylight saving time to be fully justified.

But, as I have already stressed in the introductory part, in this article I would like to touch on not at all the economic and political motives for the abolition of seasonal time transfers. I do not want to delve now into a discussion of the economic efficiency and justification of such a decision. Now I first want to highlight the technical side of the issue. Those. let's just take these time zone changes as an unavoidable reality and consider the situation from the point of view of its impact on the IT infrastructure. Pretty lyrics, go to the technical part.

What could be the problem due to changing time zones?

At first glance, the problem is obvious ...
If somewhere in your IT systems (applications / services) local time is used (for example, to display the time of some events to each client individually in his local time), then the system should have some kind of base with information about the calculation of local time in each of the world time zones. And if this base is not updated in a timely manner, then from October 30, 2011 for Russia and Belarus this base will give an incorrect calculation of local time.

Suppose you are administering a web forum. All users specify their time zone in the profile (or it is automatically calculated for the locality specified in the profile). The creation time of messages in the database of this web forum is stored on the server side in UTC format. When displaying messages to each of the users, the UTC-time of the message is corrected for the local time of the viewing user. Moreover, the size of this amendment is calculated on the server side based on a certain time zone database, which is maintained by the developers of the forum web engine.
And if the administrator of the web forum does not update this database in time, then from October 30, 2011, the calculation of local time for Russian users in this forum will not work correctly. For example, for the Moscow time specified by the user, it will be correct to make a UTC + 4 shift, and the forum will take it as before and is wrong: UTC + 3.

This obvious problem should be solved when updating the relevant information on time zones for each of the IT systems, which at least somehow uses local time in its work. In this example, update the time zone database used by the web forum.

But in reality, the problem is somewhat deeper ...
If in the regions of Russia the time zone simply changed from one to another, there would be no particular problems. It all looked like moving a computer to another country and choosing in the settings of its watch the corresponding time zone of this other country (only it would not be on the scale of one computer, but on the scale of all computers in the region, but the general principle is the same). It would not cause any problems, because almost all of the software is adapted to work with different time zones (unless, of course, it was written not by some kind of bydlokoder who tied everything up exclusively for local time without taking into account different time zones).

But in this case, for most regions of Russia (except Kaliningrad), the time zone does not change, it remains the same (with the same name), but the rules for calculating the local time inside this belt relative to UTC change. Ie, for example, earlier Moscow time (MSK) corresponded to UTC + 03: 00, and now the same time zone Moscow time (MSK) already corresponds to UTC + 04: 00. Moreover, when calculating the time of new events (for example, in December 2011) Moscow time, it will be correct to use the new Moscow time offset relative to UTC (+4), and when calculating the time of old events (for example, in December 2010) Moscow time, it will be correct to use the old Moscow time offset relative to UTC (+3), which at that time was valid for Moscow time. If you do not apply such a differentiated approach to the calculations of local time in different historical periods, then such a calculation will be inaccurate.

Suppose a certain IT system that works with local time uses a time zone database inside itself that stores current information about all world time zones in the form of a simple flat list. In this list, each time zone uniquely corresponds to a certain offset relative to UTC, which is currently in effect. Those.for example, “Moscow Time (MSK) - UTC + 03: 00”, etc. After updating this database of time zones, the entries for Russia in this list changed, in particular, it became “Moscow Time (MSK) - UTC + 04: 00”.

Those IT systems that do not update this time zone database for old events (for example, in December 2010) will calculate the local time correctly for this database, and for new events (for example, in December 2011) they will calculate the local time by this database is already wrong.

And those IT systems that still update this time zone database for new events (for example, in December 2011) will calculate the local time using this database correctly, and for old events (for example, in December 2010) they will calculate the local time on the contrary. time on this base is wrong.

Those.even after updating the database of time zones in this situation, you can get problems when working with dates (namely, with dates in the past). And all because the fundamental error lies in the very principle of storing time zones in the form of a flat list that is relevant only for the current time.

The most flexible solution in this situation is to maintain a database of time zones so that it does not just keep the current rules for calculating local time in each region of the world, but also keeps a history of changes in these rules for calculating local time. Those.the base should “remember” for each region, at what absolute time point which local time calculation rules were valid in this territory, and at what absolute time point did these rules replace with others. Knowing the correct rules for calculating local time for all regions not only for the current moment, but also for any period in the past, it is possible to accurately carry out calculations using local time in any historical period.

This is how the tzdata database ( read about tzdata more ) is arranged , which is used in many * nix-systems (including Linux, BSD, Mac OS X). And this is precisely its key advantage over other formats for storing information about time zones.

Microsoft developers have also already felt the flawed storage of information about time zones in the form of a simple list that is relevant only for the current time. For example, if you are in the Windows registry [HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones], you will expand the sections corresponding to different time zones, then in some of them you will see a subsection with the name "Dynamic DST". It just keeps dynamically changeable daylight saving time and vice versa rules depending on the year (if in some time zone these rules have changed in recent years). This changing information about time zones for different years, they began to save in the registry relatively recently.
But I still have no confidence that all software that uses the time zone database from the Windows registry correctly processes these changes for different years.

Moreover, in various conferences of developers, complaints have already appeared that after installing the patch KB2570791, the functions of calculating the local time for dates in the past began to give an incorrect result. Here for example: one and two .

The Microsoft habr blog has recommendations for developers:
habrahabr.ru/company/microsoft/blog/130629

What to do?

System and application administrators, as well as developers and other IT specialists, should prepare their IT systems in advance in order to avoid problems associated with changing time zones as much as possible.

Competently written IT systems (applications / services / DBMS) usually use the following approach to working with time:
1) Time is everywhere (all records in the database, events, logs, creation / modification dates of objects, etc.) is stored only in absolute Unix Time values (number of seconds from the beginning of the Unix-era, from 00:00:00 01/01/1970) or in UTC.
2) Time is processed (compared, added, subtracted, shifted) only Unix Time (or in UTC).
3) Information about the time zone in which the local time should be presented is stored separately. For example, to present information to users in the format of their local time, the time zone is taken from the user profile.
4) The database storing information on the rules for calculating local time in different regions of the world at different periods of time (for example, the tzdata database) is maintained and constantly updated.
5) Having the exact time Unix Time (or in UTC), the name of the local time zone and the base with the rules for calculating the local time for a given time zone, you can always accurately carry out calculations for the local time in any region for any period of time.

To perform any actions with local time, it is first translated Unix Time (or in UTC), according to the rules for calculating local time in a given time zone in a given time period, and only then processed. If the processing result should be presented in the local time format, the result is recalculated into the local time of the specified time zone, according to the rules for calculating the local time in the given time zone in the given time period.

The exact time of all events should not be recorded by the client, but by the server (at Unix Time or at UTC). Moreover, the server must have the exact time from the NTP server (or other sources of time synchronization), and must also have the current time zone database in order to make recalculations with local time.

In the world of unix-systems using tzdata, the logic of working with local time is usually organized in the same way. Therefore, there will be enough to update tzdata and nothing will not go away.

But, unfortunately, not all applications and systems can boast such a well-built logic of working with time. Somewhere may be their crutches and bicycles. And this means that changing the time zones far from everywhere will go smoothly.

Total action plan in general such:

1. Examine what updates there are about time zones for the OS, DBMS and other software you use. Read the official update recommendations from the manufacturers / suppliers of this software.
2. , , ( ).
3. - // , , /*/.
4. ( , tzdata), «», .
5. For IT professionals, it is highly advisable to browse conferences and forums of developers and administrators of software solutions you use. It is useful to share experiences with colleagues, to know in advance about those rakes that may happen in connection with the update of time zones.
6. After that, download and apply the necessary OS updates and software.
7. Prepare for possible problems and think about how to get around them.

* For example, as reported by seriyPS , in Python, the pytz library is used to work with time zones . The latest version of 2011k. Script to view the current installed version of pytz:

import pytz print pytz.__version__ 

To update the pytz library:
sudo pip install -U pytz
or
sudo easy_install -U pytz

And what if we have the exact time synchronized with NTP or GPS?

The point is that the exact time sources (NTP server, GPS receiver, atomic clock) provide exact absolute time (Unix Time). In this case, it doesn’t change at all, and everything continues evenly and continuously. You received it as before, and continue to receive it without any breaks and jumps on the time scale. Sources of exact time for all report a single absolute time, they have no idea who is where, which rules they use to get their local time from the absolute time provided by them. This is not at all a concern for sources of exact time, those systems / applications that already handle this time are involved in this.

But now if your OS or software needs to work with any local time, then this absolute time (obtained from a source of exact time or independently counted by a computer timer) on the OS or application side is recalculated at the desired local time (or back from local to absolute ). And for the implementation of error-free calculations and the correct recalculation of the local time in the OS and software, the current base of world time zones should be used.

Those. Regardless of whether your server is synchronized with a source of exact time or not, to work correctly with time zones and local time, you must have an updated global database of world time zones. Those. Having synchronization with NTP does not relieve you of the worries about updating time zone information for your IT systems.

Updating time zone information (TZI, Time Zone Information) in various operating systems

Unix systems and unix-like operating systems

Different commercial Unix systems and free unix-like systems (GNU / Linux distributions, BSD systems, etc.) use a different format for storing information about world time zones. Some vendors still independently maintain and maintain this information in their original format (for example, tztab in HP-UX) within their distribution package.

But still, most unix-like systems use the tzdata database as a single global source of information about all world time zones. The information collected in tzdata is distributed freely to everyone without any licensing restrictions (public domain). Anyone can freely take (both in source and in binary form) and use it in their applications / libraries / services. And many developers / vendors of OS distributions (in particular, Linux / BSD / MacOS) and various software do just that.

In the world of opensource, the tzdata database is the de facto standard source of information about all world time zones and the history of their changes. The tzdata database is used by all GNU / Linux distributions, BSD systems (FreeBSD, NetBSD, OpenBSD, DragonFly BSD), Solaris, UnixWare, AIX (6.1 and above), Cygwin as well as Mac OS X and some other unix-like distributions. In addition, data from tzdata is used in a number of DBMSs: MySQL, Oracle DB, PostgreSQL, etc., as well as in various languages, frameworks, libraries, modules: PHP5, Perl (DateTime :: TimeZone and DateTime :: LeapSecond modules), Python (pytz module), GNU C Library (glibc), .NET Framework (zoneinfo module), Java Runtime Environment, etc.

Official tzdata project page: http://cs.ucla.edu/~eggert/tz/
The tzdata sources and utilities for working with time zones can be downloaded here: ftp://elsie.nci.nih.gov/pub/ (the FTP server is temporarily closed for the duration of the trial ).
Mirror with all tzdata project files: http://tzmirror.appealingapps.de , ftp://tzmirror.appealingapps.de
Another mirror: ftp://munnari.oz.au/pub

In order not to overload this article, I rendered more detailed information about tzdata into a separate article .

At the time of this writing, the latest version of tzdata is 2011l (released October 10, 2011).
Changes for new time zones of Russia appeared in tzdata from version 2011h, changes for time zones of Ukraine and Belarus appeared in tzdata from version 2011k.
Since the Parliament of Ukraine has already managed to roll back its previous decree on the abolition of seasonal clock transfers, it turns out that tzdata-2011k and tzdata-2011l contain erroneous information about the time zone of Ukraine (Europe / Kiev). Therefore, for Ukraine, it will be correct to use a version or older (2011j and lower) or newer (2011m and higher). The release of the tzdata 2011m version is announced on October 24, 2011, this version should be amended for Ukraine (Europe / Kiev) and for Transnistria (Europe / Tiraspol).

Thus, in * nix-systems, in order to update information on the time zones of Russia and Belarus, which changed in 2011, it is necessary to install the corresponding update supplied by the vendor. For most distributions that use tzdata, it’s enough just to install a newer version of the tzdata package from standard repositories, ports and other embedded distribution sources and software updates used in this OS distribution.

Developers of many distributions have already released updated tzdata packages for their distributions. If you use any Linux distribution that you regularly update from the repositories, then most likely the latest version of the tzdata package is already installed on your system.
The release dates of several recent tzdata releases using the example of Ubuntu:
September 12, 2011 - tzdata sources have been updated to version 2011j;
September 14, 2011 - tzdata has been updated to version 2011j in Ubuntu upstream (Debian Unstable);
September 20, 2011 - the tzdata 2011j package entered the main Ubuntu repository;
September 26, 2011 - the tzdata sources have been updated to the 2011k version;
September 26, 2011 - tzdata has been updated to version 2011k on Ubuntu upstream (Debian Unstable);
October 04, 2011 - tzdata 2011k package entered the main repository of Ubuntu;
October 10, 2011 - The tzdata sources have been updated to version 2011l (at the time of this writing, there were no packages under Ubuntu yet).

As an option, here you can find tzdata packages for various Linux distributions:
pkgs.org/download/tzdata

In Linux distributions with package managers, you can simply see the version of the currently installed tzdata package.
In Debian / Ubuntu, this can be done with the command: dpkg -s tzdata | grep Version dpkg -s tzdata | grep Version
or apt-cache policy tzdata
In Archlinux: pacman -Si tzdata | grep Version pacman -Si tzdata | grep Version
In CentOS / RHEL: rpm -qa | grep tzdata rpm -qa | grep tzdata

If 2011h (or higher) is present in the output of this command, then in the installed tzdata version, the changes of 2011 for the time zones of Russia are already taken into account.
If 2011k (or higher) is present in the output of this command, then the installed version of tzdata already takes into account the changes of 2011 for time zones not only in Russia, but also in Belarus.

It is possible to check whether the tzdata database has been updated in the system experimentally:

1. You take several test dates in UTC format (in the past and the future, on opposite sides of the previously used DST switching dates).
2. Using the system command date, calculate the local time for these test dates in Moscow, Kiev and Minsk (using the time zone information from the tzdata database installed in the system).
3. Compare the local time calculated by the system with what should actually be.

For example, sketched a script that does it: pastebin.com/VEYt9BeN
(checked under Linux, I don’t know if it works under other * nix-systems)

He checks 5 test dates:
1. 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

For local time in Moscow should be:
1. 2010-10-01 19:00 MSD (UTC + 04)
2. 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)

For the local time of Kaliningrad, Kiev and Minsk should be:
1. 2010-10-01 18:00 EEST (UTC + 03)
2. 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)

If in your system the result of calculating the local time for these cities turned out to be different, it means that the information on these regions in tzdata is not updated.

aig said : On FreeBSD, you can upgrade tzdata from ports:
#cd /usr/ports/misc/zoneinfo
#sudo make install clean
#sudo tzsetup
And set the zone zanoovo.

On Mac OS X, the current installed version of tzdata can be found in the + VERSION file:
cat /usr/share/zoneinfo/+VERSION
In the Mac OS X Lion 10.7.2 system update, the tzdata package has been updated to version 2011h.
This means that information about the time zones of Russia has already been updated there, but information about the time zone of Belarus is not yet (for this you need at least tzdata 2011k version)

If the vendor of the Unix system you are using does not bother to release the corresponding update of binary packages for TZI, then you may have to make the appropriate changes manually. For example, independently compile tzdata using zic (Zone Info Compiler) from the latest version of the source code or copy the finished compiled zoneinfo files from the already updated system.

Some additional information about updating tzdata on * nix-systems can be found, for example, here:
www.linux.org.ru/wiki/en/Non-translation_hours_2011
www.opennet.ru/tips/2630_linux_timezone_time.shtml
www.itpad.ru/?p=2257

Cisco networking equipment

Check the current time zone configuration on Cisco equipment:

7606#sh run |i clock timezone
clock timezone MSK 3

In the output of the commands, we see which time zone is specified for local time (in this case, MSK) and what shift relative to UTC is valid for it (in this case, UTC + 3).

Now set up the correct time zone for your region and cancel seasonal watch transfers.

Cisco IOS (7206, 7600, GSR, ITP7200, ITP7200, ITP7600, AS5xxx, RPM-XF), IOS XR (ASR9k), IOS XE (ASR1k)

Run commands:
no clock summer-time
clock timezone MSK 4

The first command disables the seasonal clock translations (in particular, for the Moscow time zone, it deletes the string “clock summer-time MSK recurring last Sun Mar 2:00 last Sun Oct 3:00” from the config).
The second command sets the current time zone (in this case MSK) and the current time offset relative to UTC (in this case UTC + 4).
For other regions, instead of MSK, you should specify your time zone (for example, NSK - for Novosibirsk, VLAD - for Vladivostok). Specify here the same zone that was in the current time zone configuration (see above).

Cisco CatOS (Catalyst 6500)

Run commands:
set summertime disable
set timezone MSK 4

The first team turns off seasonal watch translations.
The second command sets the current time zone (in this case MSK) and the current time offset relative to UTC (in this case UTC + 4).
For other regions, instead of MSK, you should specify your time zone (for example, NSK - for Novosibirsk, VLAD - for Vladivostok). Specify here the same zone that was in the current time zone configuration (see above).

For more information about setting up time in Cisco IOS, see here:
galushka.com/nastroyka-vremeni-na-cisco-otmenyaem-perehod-na-zimnee-letnee-vremya

Mobile OS

Android
In Android, as in many other linux-based systems, the tzdata database is used to store information about world time zones. The tzdata package files on the Android OS file system are located along the path: /system/usr/share/zoneinfo/ . The tzdata version can be viewed in the zoneinfo.version file.
The tzdata update in Android usually happens along with updating the entire firmware. At the moment, the situation with updating tzdata in Android devices is sad. Even in the latest version of Android 2.3.6 (Nexus One, Nexus S), there are no necessary tzdata updates.

(To collect more complete statistics, please indicate in the comments: a) the model of your Android device, b) the Android version, c) the tzdata version).

About self-update tzdata (zoneinfo) on Android-devices (rutovannyh!) Can be found here:
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

The application for updating tzdata to version 2011k is in the Android Market:
https://market.android.com/details?id=com.force.timezonefixer

Maemo / MeeGo
Here, as well as in full-fledged GNU / Linux distributions, tzdata is used.
wholeman reported :
Maemo5 (Fremantle), Nokia N900 - tzdata is not updated.
Maemo6 (MeeGo 1.2 Harmattan), Nokia N9 / N950 - tzdata updated
For devices with busybox, use the date -d command 12221931.30 +% s and compare the result with 1324567890

Apple iOS (iPhone / iPad)
Apple iOS also uses tzdata as its time base. The current installed version of tzdata, as in MacOS X, can be viewed here in the /usr/share/zoneinfo/+VERSION file.
Owners of the iPhone / iPad can unsubscribe in the comments about what version of iOS is which version of tzdata. Given that iOS 5 was released quite recently, in October 2011, I have a hope that tzdata is a fairly current version there.
You can learn about self-updating tzdata (zoneinfo) on iOS (you need JailBreak) here:
habrahabr.ru/blogs/iphone/130432

Blackberry os
The company RIM (Research In Motion) has released a time zone update for BlackBerry ( KB28317 - September 2011 DST update ).

This patch updates only 7 of 9 time zones of Russia. And Omsk time (Asia / Omsk UTC + 7) and Kaliningrad time (Europe / Kaliningrad UTC + 3) are basically not supported in BlackBerry software, so they don’t have any updates for these zones either. For the time zone of Belarus (Europe / Minsk UTC + 3) there are also no updates. In this sense, the company RIM rather disregardously refers to its customers living in different time zones around the world.

If you have a corporate BES (BlackBerry Enterprise Server), administrators of this server need to install an update on this server. For this:
1. Must be installed update time zones on the server OS, where there is a BES.
2. The time zone update should be installed on corporate mail servers with which BES is integrated.
3. You need to apply a patch from RIM to the BlackBerry Enterprise Server itself (the BES update essentially consists of applying a SQL script that makes edits to the BES SQL database).

All corporate users of BlackBerry smartphones who use the connection via BES will receive the corresponding timezone update to their BlackBerry device automatically from the BES.

Private users of BlackBerry smartphones can independently download the update of time zones (KB28317) . To install the update, you need to open this link from the BlackBerry smartphone itself through the built-in browser.

Symbian, WinMobile, WP7
I do not have information about where and how popular mobile OS, such as Symbian, WinMobile 6.x and Windows Phone 7, store information about time zones. I also don’t know how they are updating this information. I will be glad to hear it from you. If someone in the know, please add in the comments.

awhiler said that time zone information was already updated on Windows Phone 7.5.

zlord said that Symbian 6.2 (Nokia 6120c) already has updated information on Russian time zones.
You can learn about updates for Nokia devices based on Symbian here:
www.nokia.ru/support/product-support/phone-software-update

MS Windows

In Windows, information about world time zones is stored in the system registry, in the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones] branch. For the time zones of Russia and Belarus there are the following subsections:

For Russia (including updates in 2011):
Kaliningrad Standard Time - (UTC + 03: 00) Kaliningrad
Russian Standard Time - (UTC + 04: 00) Volgograd, Moscow, St. Petersburg
Ekaterinburg Standard Time - (UTC + 06: 00) Ekaterinburg
N. Central Asia Standard Time - (UTC + 07: 00) Novosibirsk
North Asia Standard Time - (UTC + 08: 00) Krasnoyarsk
North Asia East Standard Time - (UTC + 09: 00) Irkutsk
Yakutsk Standard Time - (UTC + 10: 00) Yakutsk
Vladivostok Standard Time - (UTC + 11: 00) Vladivostok
Magadan Standard Time - (UTC + 12: 00) Magadan

For Belarus (excluding 2011 updates):
E. Europe Standard Time - (UTC + 02: 00) Minsk

Microsoft maintains this time base independently. they themselves monitor the completeness and relevance of this base. Changes to this database are usually made in the form of patches (updates for Windows) distributed through Windows Update.

The cumulative time zone patch (KB2570791), which includes 2011 updates for Russian time zones, was released by Microsoft on August 11, 2011:
support.microsoft.com/kb/2570791/en
support.microsoft.com/kb/2570791/en

The patch is provided for Windows versions:
- 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].
For Windows 2000 Professional / Server, the patch was not released (and will not be), because Win2k removed from Microsoft support.

On August 23, 2011, this patch ( KB2570791 ) entered Windows Update.
If your Windows systems are updated offline through the Windows Update Internet service, then they should have already received this update. If your Windows systems are updated centrally through the WSUS server in the corporate network, before the WSUS administrators should download this update to WSUS, then it will also come to all servers and workstations in your organization.
If automatic updating of Windows in your organization is not used (well, you never know), then you can independently download this patch from the Microsoft website (see the link to the article above) and install it across all Windows machines (manually, individually, by script, through group policies or via SMS / SCCM).

This patch simply makes the corresponding changes in the system registry key [HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones], the patch does not make any more changes to the system. After applying the patch ( KB2570791 ), rebooting the system is not required.
To visually make sure that this patch is installed, you can look into the system settings of time zones. The time zone shift relative to UTC should become one hour longer than before (for example, for Moscow: it was UTC + 3, and it became UTC + 4), and the checkbox, which includes the transition to summer time, should disappear.
Here is a screenshot from Win2008-R2 after installing the KB2570791 patch (using the example of Moscow):



Here is a screenshot from Win2003 (animation: before and after installing patch KB2570791 using the example of Moscow):

Upgrading Outdated Windows Systems

From my experience in large organizations, I know that the larger and more bureaucratic the organization, the slower all transitions take place there, and the slower the fleet of operating systems is updated. Therefore, in large organizations on the part of old desktops, Windows 2000 Professional still continues to work successfully. Plus, Win2k Server can live here and there on old servers, where administrators are not in a hurry to upgrade the OS from quite practical considerations: “Does it work? Dont touch him!".
If your organization includes Win2k machines as well, then you should think about updating their time zones (at least on desktops).

As mentioned above, the KB2570791 patch for Windows 2000 has not been released.
But patch KB2570791 only edits information about time zones in the Windows system registry. And the format for storing this information in the Win2k registry is no different from the format for storing this information in the WinXP or Win2k3 registry. Therefore, technically nothing prevented Microsoft from releasing this patch for Win2k as well, and without extra effort. However, Microsoft has already refused to support Win2k, so it does not release updates for it from the principle, even if it costs them nothing. This means that you will have to upgrade your Win2k machines on your own.
Enough for this:
- apply patch KB2570791 on WinXP or Win2k3;
- export the [HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Time Zones] branch from the registry of the patched system;
- take from there only the changes concerning the time zones of Russia (although it is possible to update information and in general about all world time zones, without selecting only Russian time zones);
- save these changes as a * .reg file;
- import the prepared * .reg file into the registry on Win2k machines (manually, individually, by script, through group policies or via SMS / SCCM).

You can prepare several similar * .reg files for different Windows locales (Russian, English), but you cann’t particularly bathe and use the * .reg file based on English-language Windows everywhere. It's okay if even on the Russian-language system in the settings of time zones, the display name of some of the belts will look in English.

Ready reg-files (for Russian and English locale) with edits for Russian time zones can be downloaded here:
* For English-speaking Windows: pastebin.com/FRXwDM0u
* For Russian-speaking Windows: pastebin.com/mKe3GMVU

After importing information about new Russian time zones into the registry, the current time zone should be re-indicated to the system so that the updated information about it will be re-read from the registry. Depending on the time zone in this region, this is done under Win2k / XP / 2003 by one of the commands:

For regions with Kaliningrad time (MSK-1):
control.exe timedate.cpl,,/z Kaliningrad Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time

For regions with Moscow time (MSK):
control.exe timedate.cpl,,/z Russian Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time

For regions with Ekaterinburg time (MSK + 2):
control.exe timedate.cpl,,/z Ekaterinburg Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Ekaterinburg Standard Time

For regions with Omsk time (MSK + 3):
control.exe timedate.cpl,,/z N. Central Asia Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z N. Central Asia Standard Time

For regions with Krasnoyarsk time (MSK + 4):
control.exe timedate.cpl,,/z North Asia Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia Standard Time

For regions with Irkutsk time (MSK + 5):
control.exe timedate.cpl,,/z North Asia East Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia East Standard Time

For regions with Yakut time (MSK + 6):
control.exe timedate.cpl,,/z Yakutsk Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Yakutsk Standard Time

For regions with Vladivostok time (MSK + 7):
control.exe timedate.cpl,,/z Vladivostok Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Vladivostok Standard Time

For regions with Magadan time (MSK + 8):
control.exe timedate.cpl,,/z Magadan Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

Accordingly, a batch command file for updating time zones on a Win2k computer in the European part of Russia may look like this:

regedit /s TZ-update-Russia2011.reg
control.exe timedate.cpl,,/z Russian Standard Time

or so:

regedit /s TZ-update-Russia2011.reg
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time

where TZ-update-Russia2011.reg is a REG-file with settings for Russian time zones (see above).

And when distributing this script through domain group policies, you should use the second option (the RunDLL32.exe shell32.dll is black).

Keep in mind that Win2k does not immediately update the current time zone, but at the beginning of every minute. Therefore, changes from this command will act not instantly, but with some delay (no more than 1 minute).

With regard to updating WinXP (less than SP3) and Win2k3 (less than SP2), then the patch released by Microsoft will probably not be affected either. Therefore, if you do not want to update them for some reason before the last service pack, then you will have to update them in the time zones of Russia through importing changes into the registry (by analogy with Win2k).

Features of reconfiguring time zones in Windows for different regions

Chukotka, Kamchatka
Microsoft developers have long believed that we have no summer time in Kamchatka (although in reality, as in the whole of Russia / USSR, the transition to summer time was used from 1981 to 2009, and at the end of March 2010 this Kamchatka time zone has ceased to exist). From these erroneous considerations about the absence of DST Kamchatka there, they placed Fiji in one time zone (where there really was no summer time):
Fiji Standard Time - (UTC + 12: 00) Petropavlovsk-Kamchatsky, Fiji [no DST]
Accordingly, Windows users from the regions where we used Kamchatka time (Chukotka, Kamchatka) in the settings of time zones the tick for the daylight saving time was not just removed, but there was no checkbox for the Kamchatka belt at all. And the usual standard settings of time zones to turn on summer time there was impossible.

The fix ( KB970653 ) of this bug was released only in August 2009.
In this correction, Kamchatka was removed from the belt “Fiji Standard Time” and made for it a separate belt “Kamchatka Standard Time”, i.e. after this patch, two separate belts appeared in Windows:
Fiji Standard Time - (UTC + 12: 00) Fiji [no DST]
Kamchatka Standard Time - (UTC + 12: 00) Petropavlovsk-Kamchatsky [with DST]

Due to the fact that in Windows for a very long time there was no normal time zone for Chukotka and Kamchatka (with the support of summer time), users and administrators in these regions had to get out on their own. Before the appearance of the patch KB970653, the most convenient solution was to edit the Fiji Standard Time information in the system registry to add a daylight saving time switch to this belt and enable it.
At the end of March 2010, the Kamchatka time zone was abolished in Russia, all regions from it were transferred to the Magadansky time zone. But even there, this problem was not solved (see below).

Magadan
Also, Microsoft developers have long believed that in Magadan we also have no summer time (although in reality there, as in the whole of Russia / USSR, the transition to summer time was used from 1981 to 2011). From these erroneous considerations about the absence of DST Magadan there they placed in the same time zone with the Solomon Islands, and New Caledonia (where there was no summer time):
Central Pacific Standard Time - (UTC + 11: 00) Magadan, Solomon Islands WA, New Caledonia [no DST]
Accordingly, Windows users from regions where we used Magadan time (at first it is only the Magadan region and the eastern districts of Yakutia, and since the end of March 2010 they were also joined by Chukotka and Kamchatka) the daylight saving time checkbox is not just It was removed, and there in general this checkbox for the Magadan belt was absent. And the usual standard settings of time zones to turn on summer time there was impossible.

The fix ( KB2443685 ) for this bug was released only in December 2010.
In this correction, Magadan was removed from the Central Pacific Standard Time belt and made a separate Magadan Standard Time belt for it, i.e. after this patch, two separate belts appeared in Windows:
Central Pacific Standard Time - (UTC + 11: 00) Solomon Islands, New Caledonia [no DST]
Magadan Standard Time - (UTC + 11: 00) Magadan [with DST]

Due to the fact that Windows has a very long time there was no normal time zone for Magadan (with summer time support), users and administrators in regions with Magadan time had to get out on their own. Before the appearance of the patch KB2443685, the most convenient solution was to edit the Central Pacific Standard Time information in the system registry to add a daylight saving time switch to this belt and enable it.

If new Windows installations were installed after the release of the KB2443685 patch, then administrators there after the application of this patch usually chose the correct and correct time zone by the developers: Magadan Standard Time - (UTC + 11: 00) Magadan [with DST].
But on most Windows systems that were installed before December 2010, even after applying the KB2443685 patch, the adjusted Magadan time zone appeared in the list of time zones: Magadan Standard Time - (UTC + 11: 00) Magadan [with DST], but The currently fixed independently Central Pacific Standard Time with DST added there is still selected as the current one.

Thus, now with the next repair of Russian time zones (KB2570791) on all Windows computers located in regions with Magadan time (Chukotka, Kamchatka, Magadan region, Northern Kuriles, eastern districts of Yakutia), it will be necessary to make sure that as the current time zone Magadan time is chosen. Otherwise, this patch will fix the time zone for Magadan, only this will not have any effect, since In the system, a completely different time zone is selected as the current one.

This can be done both before applying the patch KB2570791 (provided that the patch KB2443685 has already been installed) and after. You can do this either manually or automate it using scripts or via SMS / SCCM. For automation, you can use the following console commands:

In Win2k, the Magadan time zone can be selected by the console command:
control.exe timedate.cpl,,/z Magadan Standard Time
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

In WinXP / 2003, the Magadan time zone can be selected by the console command:
tzchange /c "Magadan Standard Time"
Or just like in Win2k:
control.exe timedate.cpl,,/z Magadan Standard Time
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time

In Win7 / 2008-R2, the Magadan time zone can be selected by the console command:
tzutil /s "Magadan Standard Time"

In WinVista / 2008 I I did not find the built-in console utilities for changing the current time zone, but the tzutil.exe utility, borrowed from Win7 or Win2008-R2, works here.

Sakhalin Region and Yakutia
Please note that these two regions (subjects of the Russian Federation) are not fully located within the same time zone. Some districts are located in one time zone, and some in another.
So in the Sakhalin region there are two time zones: in the North-Kurilsky district - the Magadan time (UTC + 12, MSK + 8); in the rest of Sakhalin Oblast - Vladivostok time (UTC + 11, MSK + 7).
And in Yakutia there are generally three time zones: Yakut time (UTC + 10, MSK + 6), Vladivostok time (UTC + 11, MSK + 7), Magadan time (UTC + 12, MSK + 8). The exact distribution of areas of Yakutia in these time zones, see Government Decree №725 .

The boundary between the time zones within the Sakhalin region was thus established earlier. But inside Yakutia, the border between the time zones was changed by this Government Decree No. 725.

If suddenly you have IT infrastructure in these regions, then be careful when choosing a time zone.

Samara, Izhevsk (Udmurtia)
For these regions of Russia in Windows for a long time there was no separate time zone at all. Therefore, Windows users / administrators in these regions had to search for workarounds and choose the time zone of neighboring states (usually Armenia / Yerevan or Azerbaijan / Baku) in the time settings, which used a similar time calculation. At the end of March 2010, the time zone with the Samara time (MSK + 1) was generally abolished, joining the Samara region and Udmurtia to Moscow time. And now Moscow time should be chosen in a good way in all Windows systems in these regions.
But the remnants of the old perversions with the choice of foreign time zones could still be saved somewhere in the settings of some Windows machines. Therefore, just in case, check and, if necessary, replace everywhere the time with Moscow time. You can manually, and you can again script and automate using the following commands to select the Moscow time zone:
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"(tzutil.exe copy from Win7 / 2008-R2)
Win7 / 2008- R2:tzutil /s "Russian Standard Time"

Kaliningrad
There was no separate time zone for the Kaliningrad region in Windows before, therefore, in the settings of time zones in Kaliningrad, they usually chose some European time zone corresponding to local time, for example:
FLE Standard Time - (UTC + 02: 00) Vilnius, Kiev, Riga , Sofia, Tallinn, Helsinki
E. Europe Standard Time - (UTC + 02: 00) Minsk
GTB Standard Time - (UTC + 02: 00) Athens, Bucharest

But now in the KB2570791 update for Windows for Kaliningrad they added their own time zone (without DST):
Kaliningrad Standard Time - (UTC + 03: 00) Kaliningrad
But after applying this patch, this new time zone for Kaliningrad will simply be added to the list of time zones, and it will not automatically be selected as the current one. Therefore, after (necessarily after!) Applying the patch KB2570791 on Windows-based computers in Kaliningrad, it will be necessary to select Kaliningrad time for the system in the settings of time zones. You can do this manually, but you can again script and automate using the console commands to select the Kaliningrad time zone:
xp, 2003: tzchange /c "Kaliningrad Standard Time"
2k, xp, 2003:
control.exe timedate.cpl,,/z Kaliningrad Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time
WinVista / 2008: tzutil /s "Kaliningrad Standard Time"(tzutil.exe copy from Win7 / 2008-R2)
Win7 / 2008-R2:tzutil /s "Kaliningrad Standard Time"

Belorussia
As for changing the time zone in Belarus, Microsoft is aware of this, but now they will not release the corresponding Windows patch for time in Belarus. They, apparently, are too lazy to strain and get out of the planned schedule of cumulative updates. They plan to include time zone changes for Ukraine, Belarus and Armenia in the next cumulative update of Windows time zones, which will be released in December 2011. But it is not yet clear whether there will be any legislative decisions on this in Armenia and Ukraine by that time. Until then, Microsoft offers its Windows users from Belarus to use the crutch to manually grind tuna by themselves:
1) Install the patch KB2570791 , which changes the time zone of Russia.
2) For users from Belarus, select as their time zone: (UTC +3: 00) Kaliningrad

And after December 2011, the next cumulative WinUpdate time zones will be released, in which they will finally correct the time zone for Belarus (and It is possible for Ukraine and Armenia too), they suggest that all users from Belarus install this update, and then again, manually in the system time settings, return the time zone to the native (already approved) for their country.

This is not at all my invention, here is the official article from Microsoft in which it is written about it:
support.microsoft.com/kb/2625508/en
support.microsoft.com/kb/2625508/en

The installation of the Kaliningrad time (after the KB2570791 patch) for Belarus can be done manually, and can again be scripted and automated, using the console commands to select the Kaliningrad time zone:
xp, 2003: tzchange /c "Kaliningrad Standard Time"
2k, xp, 2003:
control.exe timedate.cpl,,/z Kaliningrad Standard Time
or
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time
WinVista / 2008: tzutil /s "Kaliningrad Standard Time"(tzutil.exe copy from Win7 / 2008-R2)
Win7 / 2008-R2:tzutil /s "Kaliningrad Standard Time"

Update time zones on MS Active Diectory domain controllers

You just need to install the patch KB2570791 on the servers of domain controllers, as well as on any other Windows-machines. To make no difference on domain controllers, it is advisable to install this update on all AD forest controllers on the same day.

There is one bug I know about updating controllers. If in your organization for any paranoid security requirements for users, the logon Hours time limit is set and, accordingly, your users have a completed logonHours attribute, then immediately after installing the KB2570791 update on the domain controllers for all users, the authorized login ranges are the system will shift by an hour . You will feel this problem not after October 30, but immediately after the patch controllers.
For example, if the allowed login time for your users was set to range from 9 to 18 hours, after the patch of domain controllers, users will be allowed to log in from 10 to 19 hours. Those.users who will come to work with such restriction the next morning will not be able to log in until the administrator removes this restriction or until 10 am.

Moreover, this interval of allowed logon will be moved only on those controllers where the patch KB2570791 was installed. And if you have this patch installed on some controllers, but not on others yet, it may happen that some users could log in (since they hit the unpatched controller when logon), and others could not (because when logon got to the already patched controller), although initially they had the same permissions for the time of logon. This circumstance may make it harder for you to diagnose the problem.

Therefore, before installing the KB2570791 patch on domain controllers, you need to estimate how many users in your domain have a logon time limit in the system. To do this, you can upload to the file a list of users with their logonHours and examine it. An example of a PowerShell script for uploading users with the logonHours attribute: pastebin.com/0Ucu7MKi

If there are no such users, then everything is OK, all controllers can be patched painlessly. If there are such users in AD, then the problem with them needs to be somehow solved. There are two obvious options:
1) Refuse these restrictions on the login time and all users fill in the logonHours attribute so that there are no restrictions on the login time (it can be a script);
2) Write a script that all users will shift all ranges of logonHours one hour ago, and run this script immediately after the patch of all domain controllers.

Update time zones on MS Exchange servers

With the storage of information about time zones in the mail system Exchange, some kind of mess is going on.
The most expected problem with the Exchange mail system with this change of time zones is the out-of-synchronization of calendar events in different calendars. Suppose a business meeting of the board of directors is scheduled for 10 o'clock, but one of the participants saw it in his calendar at 9 o'clock (and came an hour earlier), another saw it in his calendar at 10 o'clock (and came on time), and the third saw it in his calendar at 11 o'clock (and was late for an hour).

For example, one-time events added to the calendar and regularly recurring events (for example, annual) are stored in the Exchange mail database in various formats: in one case, the time zone is stored together with the specified time, and in the other case it is not stored. And when you change the time zones it will matter.
Even when accessing the same calendar through MS Office Outlook and through OWA (Outlook Web Access), you can see different data, because OWA has its own view on time zone information.

Plus, the correctness of displaying calendar events in different calendars may be affected by other factors:
- What versions of Outlook are on the sender and recipient computers;
- the mailbox is stored on the server in the mail database or locally in the PST file;
- whether or not Windows systems are patched on both sender and recipient computers;
- the sender and the receiver are in the same time zone;
- before the patch is installed or after the calendar event is created;
- whether or not the Windows systems are patched on the Exchange mailbox servers hosting the sender and recipient boxes;
etc.

And in most cases there may be no problems with desynchronization of calendar events, but with some combination of the factors outlined above, some events in different calendars may even go away in time.

For example, if a user from a Windows machine without an installed update KB2570791 has scheduled a meeting in his calendar, for example, on November 1, 2011 (or the next day after October 30, 2011) from 10:00 to 11:00, and then sends an invitation to this an appointment to a user who already has KB2570791 on a Windows machine, the sender and the recipient will see this event in their calendars at different times. The sender has from 10:00 to 11:00, and the recipient has from 11:00 to 12:00, so he risks being late for this meeting.
And vice versa, if you create a meeting for a date after October 30 on a patched machine and send an invitation to a user on a non-patched machine, the time shift by one hour will be in the opposite direction. The most annoying thing here is that the sender and the recipient of calendar events can be generally from different organizations. So you can install patches on both of their machines; you simply may not have any technical possibility (only one of these users can be controlled by the computer).

According to Microsoft, the issue of storing information about time zones is more or less combed in Exchange 2010, but when using Exchange 2003 and Exchange 2007, the indicated problems with desynchronization of calendar events are quite possible. And sruzu after installing the patch KB2570791problems may not appear on client workstations and on Exchange servers, but after October 30, 2011, the unpatched Windows systems were shifted by an hour ago, then such problems with calendars are possible.

Microsoft support does not give an unambiguous answer about how it is guaranteed in advance to secure your Exchange email system from such problems, but their recommendations are as follows:
1. Install the KB2570791 patch on all client Windows machines;
2. Install the patch KB2570791 on all Exchange-servers of the organization and on all domain controllers;
3. If you have Exchange 2007 servers (SP3), then install Update Rollup 5 on them ;
4. Further observe and identify problems with calendar events of users.
5. If users complain about the shift of calendar events in their calendars, then:
a) either on the server side, run the Exchange Calendar Update Tool to fix calendars on specific servers for specific problem users;
b) either on the client side, launch Outlook Time Zone Data Update Tool to fix calendars on the Outlook side.

Update time zones on MS Sharepoint servers

On servers with MS SharePoint, first, you should install the Windows update KB2570791 , and second, install the update for SharePoint itself:
- update for MS SharePoint 2007 (SharePoint Serveces 3.0) ;
- update for MS SharePoint 2010 .

See also information about updates of time zones for Microsoft products here:
support.microsoft.com/gp/cp_dst/en
support.microsoft.com/gp/cp_dst/en

When do I need to update information about time zones in the OS and software?

Formally, Russia and Belarus already have a new time calculus in time zones (see the adopted laws ). Therefore, all OS / software updates related to this can already and should be done. Moreover, all the work on updating the time zones should be done before October 30, 2011. Because systems with new information about new time zones, October 30 (the last Sunday of October) will try to return from standard time to summer (because they do not know that the transitions already canceled), and this can cause problems (at least problems with incorrect display of local time).

Until the time H remained only a couple of working weeks. Therefore, do not postpone these works in the long box. Once again, carefully review your IT economy (servers, applications, services, etc.), plan and carry out work to update information on time zones wherever possible.

One can only hope that these problems will not affect the systems of your company level BC (Business Critical) and MC (Mission Critical). For example, if your business is tied to billing systems or some accurate financial calculations that are tied to local time (both in the present and in the past), then the problems that have arisen over time can cause quite specific business losses for you.
Addressing non-critical OP-level systems (Office Productivity), such as the shift by hour of some calendar events in Outlook, is usually not significant from a business point of view.

Of course, you should not panic, but be prepared for the fact that problems associated with changing time zones in some IT-systems are very likely. If not immediately after your application of patches / fixes, then from October 30, 2011 surely.

See also another topic on changing time zones in Russia:
Moving the MSD time zone to MSK - a new local scale Y2K

Article author: Roman Tik <ya.roman.tik {at} yandex.ru> The text of the article is distributed under the terms of the license Creative Commons Attribution 3.0 Unported (CC BY 3.0). You can freely copy, edit and use for any purpose this text with the obligatory indication of authorship.