Why is the local time zone used in CAP?

[leftjoinandinnerjoin]

Description

When we scale out instances horizontally, if the local time zones of the two instances are inconsistent, it can cause confusion in the Added and ExpiresAt times when writing data to the database.

The following are examples of data :

Instance A Time zone : UTC +0 & Instance B Time zone : UTC +8

Published table

Id	Content	Added	StatusName
Published1	{"sendTime":"2024-04-15 03:00:00.0000000"}	2024-04-15 03:00:00.0000000	Succeeded
Published2	{"sendTime":"2024-04-15 11:00:00.0000000"}	2024-04-15 11:00:00.0000000	Succeeded

Received table

Id	Content	Added	StatusName
Received1	{"sendTime":"2024-04-15 03:00:00.0000000"}	2024-04-15 03:00:01.0000000	Succeeded
Received2	"sendTime":"2024-04-15 11:00:00.0000000"}	2024-04-15 11:00:01.0000000	Succeeded

Question

Why is UTC time not uniformly used when designing CAP? Is there any problem that cannot be solved?

Future

Suggest using UTC time zone uniformly for the time used in CAP.

[yang-xiaodong]

Using the local time zone makes the data easier to read for humans. Unless a major bug occurs, we will not adjust to using UTC for data compatibility.

I have a question, why do your instances have different timezone when scaling horizontally, aren't you specifying the time zone in Docker?

[leftjoinandinnerjoin]

Thank you for @yang-xiaodong reply.

I understand what you mean. When we horizontally expand the same application, we should ensure that the time zone is consistent. This is a correct suggestion.

But if the time zones of the sender and receiver of the message do not match, it will cause confusion in the corresponding sendTime in the Content. Can we change the time type to DateTimeOffset? that this can solve this problem.

[91651]

Issues can easily arise in international projects. A reasonable approach is to use UTC(DateTime.UtcNow) time for message storage and processing to avoid problems caused by time zone differences.

[yang-xiaodong]

@leftjoinandinnerjoin

But if the time zones of the sender and receiver of the message do not match, it will cause confusion in the corresponding sendTime in the Content. Can we change the time type to DateTimeOffset? that this can solve this problem.

I don't think so, if the publisher and the consumer are in different time zones, then the corresponding apps are in different time zones, for the publisher to see his time zone, and for the consumer to see his own time zone

[yang-xiaodong]

@91651

Issues can easily arise in international projects. A reasonable approach is to use UTC(DateTime.UtcNow) time for message storage and processing to avoid problems caused by time zone differences.

For the use case in our international project, this is not an issue; the time zone displayed on the front-end and the time zone stored do not need to be strictly the same. All times are converted to UTC and returned to the frontend for formatting into local time.

[yang-xiaodong]

The requirement described in issue #895 is reasonable for Daylight Saving Time switching, but our investigation found that some databases don't support storing DateTimeOffset, so we won't deal with it for now.

[91651]

@yang-xiaodong

你上面说的对，并不是所有数据库都支持DateTimeOffset，这一点在.net上是非常友好的，我们在兼容性角度，确实不应该轻易采用DateTimeOffset。
但是在CAP使用DateTime.UtcNow处理时间是完全兼容的，这和用DateTime.Now并没有区别，但是可以解决当开发者不在同一时区或者服务器没有配置时区时所有发送者和订阅者处理消息都在同一时间维度。

当然，采用timestamp也可以解决，但这个更为繁琐。

[yang-xiaodong]

Closed, Won't fix now.