How to solve cross-time zone problems in distributed systems [principles]

About the most familiar System. dateTime [previous article] [next article] discusses the well-known DateTime type from the perspective of cross-time zone. They are all preparations for this article. In the next two articles, we will introduce how to handle time zone issues in a distributed system.

I. scenarios and requirements

In order to give you a more intuitive understanding of the topic introduced in this article, we will provide a specific application scenario. A multinational company develops a unified office system for all branches around the world. The UI of the Client uses Smart Client (Windows Forms Application), and the main business logic is provided in the form of a WCF Service. We will turn the server that carries the business service into an application server, as shown in the figure on the right (see the figure below). The application server Department belongs to China (Zone 8 in the east ). The main clients (subsidiaries) are distributed in three major countries and regions: North America, Europe and Australia.

Regardless of the time zone between the client and the server, or between different clients, there will be some trouble during time processing:Which time zone should a client obtain through a service call based on?Different scenarios may have different requirements for this problem. In most cases, the time value we want to obtain is based on the local time zone of the client. However, in some scenarios, the time zone corresponding to the time value we want to obtain is the time zone based on which the object is described. For example, when the US branch opened its business at a.m. on January 1, September 1, employees of the European branch did not have to convert the time to the local time zone.

However, this article does not consider this situation. Our final requirement is:Client applications do not need to consider the time zone, just like a local application. The time input by the client to call the service is DateTimeKind. Local time or DateTimeKind. Unspecified time. Similarly, the time returned by the service call should also be based on the time in the time zone of the client.

Ii. solution implementation principles

Now let's talk about how to solve the problems mentioned above. Since the time zone cannot be processed on the client, in other words, it must be implemented on the server. One of our prerequisites is:No information about the time zone is stored in the database.. To achieve the above objectives, we need to solve two problems: saving time and obtaining time.

In terms of saving time, since the database can save information such as any time zone offset. In this case, we must make all the time stored in the database based on the same time zone. We can chooseTime zone of the Application ServerYou can also directly useUTC time. Our solution adopts the latter, that isSave all database time as UTC time.

The storage format of the time in the database is determined, and now there is another problem: the time sent from the client is the local time in the time zone of the client, after the server receives the time sent by the client, you must convert the time zone from the client to UTC to save it to the database. Then, how does the server obtain the time zone information of the client? Using it as a service operation parameter is certainly not desirable.

If you have read my previous articles in the WCF series, you may remember an article about how to transfer context between the client and the server through the WCF extension:WCFExtension implementationContextInformation Transmission. In this article, I used the WCF extension to automatically transmit the user-end Culture and UICulture to the server, so as to ensure that the two sides store the same language and Culture environment context.If we can pass the TimeZoneInfo on the client as the context, we can solve the problem of time zone identification on the client on the server..

You can use the sequence diagram above (click to view the large image) to describe how to save the time. The client uses the DateTimeKind. Local or DateTimeKind. Unspecified time of the Local time zone as the input operation to call a service. At the same time, the Local TimeZoneInfo is serialized and transmitted to the server as the context. The server converts the received time to DateTimeKind. Utc Based on the received TimeZoneInfo context and saves it to the database.

When the client calls the service to obtain a certain time, the local information is also transmitted to the server as the context information. With this TimeZoneInfo, the server can convert the time saved in the database in UTC format to the DateTimeKind. Local time based on the client time zone. The sequence diagram shown in the right (click to see the big picture) reflects this process.

Iii. serialization of TimeZoneInfo

In the introduction to the TimeZoneInfo class in System. DateTime [previous], I said this class can be serialized. serialization is very important for solving cross-time zone problems. This is because we need to pass TimeZoneInfo as the context on the client and the server. In other words, we need to serialize the TimeZoneInfo object and put the serialized content into the Outgoing Message) in the Message Header.

However, for TimeZoneInfo Object serialization, we generally do not actually deliver the entire TimeZoneInfo object to the serializer for serialization, we use two special methods defined in TimeZoneInfo for serialization and deserialization. One is the instance method ToSerializedString, which converts TimeZoneInfo into a serialized string; the other is the static method FromSerializedString, which deserializes serialized characters to generate a TimeZoneInfo object. The two methods are defined as follows:

   1: [Serializable]

   2: public sealed class TimeZoneInfo

   3: {

   4:     //Others

   5:     public static TimeZoneInfo FromSerializedString(string source);

   6:     public string ToSerializedString();

   7: } 

The following code demonstrates the serialization and deserialization of TimeZoneInfo through the above two methods:

   1: string serializedString = TimeZoneInfo.Local.ToSerializedString();

   2: Console.WriteLine("SerializedString: {0}\n", serializedString);

   3: TimeZoneInfo deserializedTimeZone = TimeZoneInfo.FromSerializedString(serializedString);

   4: Console.WriteLine("deserializedTimeZone.Equals(TimeZoneInfo.Local) ? {0}", deserializedTimeZone.Equals(TimeZoneInfo.Local));

   5: Console.WriteLine("deserializedTimeZone == TimeZoneInfo.Local ? {0}", deserializedTimeZone == TimeZoneInfo.Local);

The following is the output result, from which we can see the content of the final serialized text. In addition, the output results also reflect two other information: Two TimeZoneInfo objects that contain time zone information,Call the Equals method and use the = Operator to obtain different results.. I personally think this is a poor place for Microsoft.

   1: SerializedString: China Standard Time;480;(UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi;China Standard Time;China Daylight Time;;

   2:  

   3: deserializedTimeZone.Equals(TimeZoneInfo.Local) ? True

   4: deserializedTimeZone == TimeZoneInfo.Local ? False

The cross-time zone issue in this distributed system is now discussed here. In the next article, I will provide a complete example, I believe that you will have a deep understanding of the solution provided in this Article.

[Read More][1] about the System you are most familiar. dateTime [Part 1] [2] about the System you are most familiar. dateTime [next] [3] How to solve cross-time zone problems in distributed systems [principles] [4] How to solve cross-time zone problems in distributed systems [Example] Author: Artech

Source: http://artech.cnblogs.com/

The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.