The defect of DateTime in C # And the replacement product DateTimeOffset,

The defect of DateTime in C # And the replacement product DateTimeOffset,

DateTime in C # has a very serious logical defect:

> var d = DateTime.Now;> var d2 = d.ToUniversalTime();> d == d2false> d.Equals(d2);false

In the C # interaction mode, enter the above Code. Although one is local time (d) and the other is UTC time (d2), the only difference is the time zone, but in this world, it should belong to the same time. However, the two time periods are not equal...

The reason is that DateTime does not store the time zone, or only stores a fuzzy Kind field about the time zone. It is of the DateTimeKind Enumeration type and has three values: Utc/Local/Unspecified, when the value is Unspecified, there will be ambiguity.

But I still want to vomit, if any of d. Kind or d2.Kind is Unspecified, then d! = D2 I can understand. But the above d. kind is Local, and d2.Kind is Utc. If the logic of DateTime does not store the time zone, the two must be equal when they are converted to Utc or Local in a unified manner. In fact, the same is true:

> d == d2.ToLocalTime()true

If the local time t1 of d is treated as 9, the local time zone z1 is treated as + 8, the corresponding UTC time t0 is regarded as 1, and the UTC time zone z0 is regarded as 0, normalize them:

D = t1-z1 = 9-8 = 1, d2 = t0-z0 = 1-0 = 1.

However, d! = D2. This is where it is.

Take the GMT + 8 as an example. In the C # interactive mode, enter the following code:

> var d3 = new DateTime(2018, 1, 1);> d3[2018/1/1 0:00:00]> d3.ToLocalTime()[2018/1/1 8:00:00]> d3.ToUniversalTime()[2017/12/31 16:00:00]

It can be found that a simple constructor generally uses local time by default. However, it allows developers to create a monster that is neither local time nor UTC time.

When d3 is converted to the local time, d3 is used as the UTC time to add 8 hours.

When d3 is converted to UTC, d3 is used as the local time to reduce 8 hours.

So is d3 local time or UTC time? No one knows, unless it exists in a very small local scope and has a very short lifecycle, we may assume that it is local time.

However, this local time also depends on its running environment. If there are several computers with different time zones, the DateTime that caws the time zone information is converted into a string and transmitted to another server in the network (for example, the 11th Zone Next Door). After parsing, the so-called UTC + 8 local time is, in Japan, it became a monster of neither local time nor UTC time.

DateTime is no longer recommended in official documents. Instead, it is recommended to use its substitute DateTimeOffset, which saves time zone information.

Verify in interactive mode:

> var dto = DateTimeOffset.Now;> var dto2 = dto.ToUniversalTime();> dto == dto2true

It can be found that the DateTimeoffset criteria for determining whether two times are equivalent are determined based on the time point of the world timeline, which is irrelevant to the time zone or even UTC time. As long as they are in the same time system, they can change each other.

In actual projects, we recommend that you:

• If DateTime is used, all values are converted to DateTimeOffset.
• If a 32-bit UNIX timestamp is used, replace it with a 64-bit long to store UtcTicks.

Even if the project itself does not span time zones, you may still encounter time zone problems. For example, if you use mongodb, mongodb stores all the time in UTC (as if you forgot to save it ), in addition, it generally carries time zone information. However, there is a bad situation. If your DateTime Kind is Unspecified, the information about the hidden time zone will be lost. Then, there will be an 8-hour time difference. There are some third-party or company class libraries. If this problem is not handled properly, there are also potential time zone loss problems. It is also advantageous to save UNIX timestamps to Utc Ticks. Both precision and time span far exceed the UNIX timestamp. You only need 64 bits to get the precision of up to 100 nanoseconds. The time span of over years can be used once and for all, whether it is a UNIX timestamp or a JS timestamp. The cost of space is also very small, unless your storage space is really hard to hurt ..