和哥们聊着聊着聊的我血压起来了

有一说一，Java 的 DateTime 类型是真的垃圾。。。C＃的 DateTime 也还行吧，没啥大毛病，用起来确实也挺方便的。

其实如果单纯论 datetime 什么的都无所谓，最头疼的是《新的》，我不知道这新在哪里，而且按微软的说法

DateTimeOffset 值的使用频率比 DateTime 值的更高。

只看你这个图，如果这是他的真心想法，那么属于既不懂 java 又不懂 dotnet ，是我就直接屏蔽了。

DateTime 比 DateTimeOffset 大？微软文档里说 The DateTimeOffset structure includes a DateTime value, together with an Offset property
learn.microsoft.com/en-us/dotnet/api/system.datetimeoffset
如果是我我也不会选择使用 DateTimeOffset ，具体时区使用系统时区或者提供设置选项让用户改时区。个人认为在时间值中存时区反而会导致混乱。以及可能泄漏个人隐私，比如 Git 的 commit date 就包含时区，可以以此推测用户地区。

时区真的烦.
最好是所有时间都用 epoch.只有表示给 user 看时, 才使用 user 的本地时区转换下.

没必要存时区, 使用时再转换.

个人的看法，对时区之类的细节，在 prototyping 的时候不会去特地考虑，毕竟首要任务是弄个 demo 出来。

但是到了 production 的阶段，这些细节都是需要解决的吧。除非在写的是应付学校的作业。

把.Net Framework 时代的东西称为「新的第三方不稳定 API 」也实在太典了。

DateTime 的 UTC 首选对吗（
为什么微软说 DateTimeOffset 使用的频率更高呢
说到时区，DateTime 里面也有保存时区的成员
以后可以仔细分析一下具体区别，比如大小和效率

如果对方的程序只运行在当地时区下，而且与当地时区相关，那么使用 DateTime 是非常好的选择。
如果对方的程序需要经常处理与 UTC 相关的转换（如地方时区转成 UTC ），那么用 offset 意味着你得手动处理这个转换，而且肯定没微软搞的那个稳，此时也应该用 DateTime.
如果你的程序内需要一个时间戳，但与本地时区无关，则使用 DateTimeOffset.
微软的文档有时候写得不是那么容易理解的。

而且微软那个 note ，我这么说吧，纯粹是为了掩盖掉他们整错了这俩玩意儿的名称的做法……DateTimeOffset 很容易被理解为与 x 时间做的一个差值，还不如叫 AbsoluteTimestamp 呢……
所以凡是要以当地时区计时的东西（尤其是某些 log 必须跟着计算机时间走的），一定用 DateTime 。

一律用 timestamp

utc 好复杂 timestamp +1
timestamp +1 不需要考虑什么时区问题

LocalDateTime 用起来爽翻天呀

看看这里的回帖就知道什么叫油盐不进了。。。

我不懂，我不学，我就用这个

存 utc 既简单又方便 需要的时候再根据时区转就好
如果非要存的话也不太建议存单纯的 offset 而是建议存类似 TimezoneInfo 之类的东西(不过感觉.net 应该是考虑过这个东西的 俺写 java 的对这玩意儿不太了解😄)
之前做海外业务的时候曾经就被冬夏令时转换这玩意儿支配过

不在一个逻辑里多说无益

Java 不用 LocalDate 、LocalDateTime 吗？

看了你截图里的 learn.microsoft.com/en-us/dotnet/standard/datetime/choosing-between-datetime
微软也是推荐用的 DateTime, 只有当你确实需要处理时区问题的时候才推荐 DateTimeOffset, 你同学 /朋友 /同事说的没错.
The DateTime structure is suitable for applications with one or more of the following characteristics:
Work with dates and times for which time zone information is missing.
Work with UTC dates and times only.

The DateTimeOffset type includes all of the functionality of the DateTime type along with time zone awareness. This makes it suitable for applications that:
Uniquely and unambiguously identify a single point in time.
微软这里说的就是, 不关心时区你就用 DateTime, DateTime 里有个 Kind 属性指明是针对当前时区,UTC 时区,还是没有时区.
而 DateTimeOffset 则含有明确的时区定义.
就国内全国统一一个时区而言, 用 DateTime 有什么问题?

“能用旧的绝不用新的”这句话才是血压来源吧

微软的.net 看不见源码，对于新东西的使用没有掌控力

看起来他并不太懂 Java ，，有什么理由不用 LocalDate 、LocalDateTime ？

我一直认为表示时间值与时区无关，所有时间值都是 UTC 或时间戳，而时区只是对时间值 format 展示时的一项参数。

一律用 uint64_t

他明白你说的意思，你也知道他不想用。为什么非要强迫他接受呢。

他说得对，他能够为自己的代码负责，而你和微软都不能。

理由说得很明白，项目中本来都是使用 DateTime 的，而且可以满足需求，换成 DateTimeOffset 除了「微软推荐」外没有特别的好处（看 .net7 源码的话，DateTimeOffset 里面就包含一个 DateTime ，Add 操作都是调的内部 DateTime 的同名 API ，不降低效率就不错了）。

他说的「新」应该是相对于项目里的旧代码而言，DateTimeOffset 是一个新的东西，在对付旧项目的时候，复用项目已有的逻辑是较为稳妥的，更别提这玩意是可能万年不更新的固件了，炸了更头疼。

其实 DateTimeOffset 也有一些需要考虑的问题，某些外部数据源很可能只能使用 DateTime （例如 SQLite 不支持 DateTimeOffset 类型），这一点他间接考虑到了（某些三方库可能会出问题）。

而你只是说微软推荐就建议他用，根本没有告诉他可能出现的问题，你似乎也对这个项目不太了解，屎山炸了你也不能负责，然后因为他的保守而生气挂人。还是放下助人情结，尊重他人命运，这样双方的心情都会好很多。

DateTimeOffset: github.com/dotnet/runtime/blob/8ccdb1cd29754ed64a451300cd1fc59d35b88d40/src/libraries/System.Private.CoreLib/src/System/DateTimeOffset.cs＃L62

替换 DateTime 为 DateTimeOffset 的前提是，他的项目有足够高的 test case 覆盖率，否则就是自掘坟墓

带着要赢的心态对话，自然会血压高的

有一说一我都是习惯存 epoch time 来着

赞同

如果我是对方，跟题主这样聊也会血压升高，一味的微软建议而又说不出什么实质性优势，而且 2-3 个字甩过来，感觉高冷+不耐烦。

这个话题又要再来一次么？我以前说用时间戳，被骂的狗血淋头...

DateTimeOffset = DateTime + Offset
本来就是不等价的东西，用在不同场景，哪有什么一个比另一个好？

＃14 redisson + LocalDateTime = 苦痛面具

那是他们菜啊

红心怎么点 想赞 ikesnowy 老哥

......什么是时区？？？

回复 icon 左边，感谢回复者

不知道你在说什么： github.com/dotnet/runtime

抛开场景谈建议本身就没什么意义，正如楼上某位 XD 说的，op 和微软根本不用为他的项目负责，当然随便建议。
对方说得已经很清楚了，效率差距不明显，固件代码重在稳定，抱着书本非要辩赢那当然血压上升

非 geek：能用就别动！
geek：这个按钮有什么用？

我司时间大部分都是时间戳，前端自己转。