Why is the local time zone used in CAP? about cap HOT 8 CLOSED

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?

from cap.

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.

from cap.

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.

from cap.

@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

from cap.

@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.

from cap.

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.

from cap.

@yang-xiaodong

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

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

from cap.

Closed, Won't fix now.

from cap.