V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Aloento
V2EX  ›  程序员

《油盐不进》

  •  1
     
  •   Aloento · 2023-01-08 23:48:43 +08:00 · 7410 次点击
    这是一个创建于 707 天前的主题,其中的信息可能已经有所发展或是发生改变。

    0yWXL.jpeg 和哥们聊着聊着聊的我血压起来了

    45 条回复    2023-01-25 12:56:14 +08:00
    xuanbg
        1
    xuanbg  
       2023-01-08 23:55:20 +08:00
    有一说一,Java 的 DateTime 类型是真的垃圾。。。C#的 DateTime 也还行吧,没啥大毛病,用起来确实也挺方便的。
    Aloento
        2
    Aloento  
    OP
       2023-01-09 00:05:21 +08:00
    @xuanbg 其实如果单纯论 datetime 什么的都无所谓,最头疼的是《新的》,我不知道这新在哪里,而且按微软的说法
    > DateTimeOffset 值的使用频率比 DateTime 值的更高。
    ragnaroks
        3
    ragnaroks  
       2023-01-09 00:27:43 +08:00
    只看你这个图,如果这是他的真心想法,那么属于既不懂 java 又不懂 dotnet ,是我就直接屏蔽了。
    ysc3839
        4
    ysc3839  
       2023-01-09 03:02:28 +08:00 via Android
    DateTime 比 DateTimeOffset 大?微软文档里说 The DateTimeOffset structure includes a DateTime value, together with an Offset property
    https://learn.microsoft.com/en-us/dotnet/api/system.datetimeoffset
    如果是我我也不会选择使用 DateTimeOffset ,具体时区使用系统时区或者提供设置选项让用户改时区。个人认为在时间值中存时区反而会导致混乱。以及可能泄漏个人隐私,比如 Git 的 commit date 就包含时区,可以以此推测用户地区。
    dcoder
        5
    dcoder  
       2023-01-09 03:25:31 +08:00
    时区真的烦.
    最好是所有时间都用 epoch.只有表示给 user 看时, 才使用 user 的本地时区转换下.
    lslqtz
        6
    lslqtz  
       2023-01-09 03:35:27 +08:00   ❤️ 4
    没必要存时区, 使用时再转换.
    netabare
        7
    netabare  
       2023-01-09 06:11:38 +08:00   ❤️ 1
    个人的看法,对时区之类的细节,在 prototyping 的时候不会去特地考虑,毕竟首要任务是弄个 demo 出来。

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

    把.Net Framework 时代的东西称为「新的第三方不稳定 API 」也实在太典了。
    Aloento
        8
    Aloento  
    OP
       2023-01-09 06:29:48 +08:00
    @ysc3839 DateTime 的 UTC 首选对吗(
    为什么微软说 DateTimeOffset 使用的频率更高呢
    说到时区,DateTime 里面也有保存时区的成员
    以后可以仔细分析一下具体区别,比如大小和效率
    mingl0280
        9
    mingl0280  
       2023-01-09 07:49:10 +08:00 via Android   ❤️ 3
    如果对方的程序只运行在当地时区下,而且与当地时区相关,那么使用 DateTime 是非常好的选择。
    如果对方的程序需要经常处理与 UTC 相关的转换(如地方时区转成 UTC ),那么用 offset 意味着你得手动处理这个转换,而且肯定没微软搞的那个稳,此时也应该用 DateTime.
    如果你的程序内需要一个时间戳,但与本地时区无关,则使用 DateTimeOffset.
    微软的文档有时候写得不是那么容易理解的。
    mingl0280
        10
    mingl0280  
       2023-01-09 07:54:02 +08:00 via Android   ❤️ 1
    而且微软那个 note ,我这么说吧,纯粹是为了掩盖掉他们整错了这俩玩意儿的名称的做法……DateTimeOffset 很容易被理解为与 x 时间做的一个差值,还不如叫 AbsoluteTimestamp 呢……
    所以凡是要以当地时区计时的东西(尤其是某些 log 必须跟着计算机时间走的),一定用 DateTime 。
    securityCoding
        11
    securityCoding  
       2023-01-09 08:39:09 +08:00 via Android
    一律用 timestamp
    YVAN7123
        12
    YVAN7123  
       2023-01-09 08:49:43 +08:00
    utc 好复杂 timestamp +1
    @securityCoding
    yaott2020
        13
    yaott2020  
       2023-01-09 09:02:14 +08:00 via Android
    timestamp +1 不需要考虑什么时区问题
    cubecube
        14
    cubecube  
       2023-01-09 09:42:03 +08:00
    @xuanbg LocalDateTime 用起来爽翻天呀
    Mithril
        15
    Mithril  
       2023-01-09 10:02:28 +08:00   ❤️ 1
    看看这里的回帖就知道什么叫油盐不进了。。。

    我不懂,我不学,我就用这个
    NizumaEiji
        16
    NizumaEiji  
       2023-01-09 10:04:11 +08:00
    存 utc 既简单又方便 需要的时候再根据时区转就好
    如果非要存的话也不太建议存单纯的 offset 而是建议存类似 TimezoneInfo 之类的东西(不过感觉.net 应该是考虑过这个东西的 俺写 java 的对这玩意儿不太了解😄)
    之前做海外业务的时候曾经就被冬夏令时转换这玩意儿支配过
    FreshUncle
        17
    FreshUncle  
       2023-01-09 10:10:57 +08:00
    不在一个逻辑里多说无益
    zydxn
        18
    zydxn  
       2023-01-09 10:16:50 +08:00
    Java 不用 LocalDate 、LocalDateTime 吗?
    bthulu
        19
    bthulu  
       2023-01-09 10:28:41 +08:00
    看了你截图里的 https://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 有什么问题?
    Huelse
        20
    Huelse  
       2023-01-09 10:32:39 +08:00
    “能用旧的绝不用新的”这句话才是血压来源吧
    Mirana
        21
    Mirana  
       2023-01-09 10:37:30 +08:00
    微软的.net 看不见源码,对于新东西的使用没有掌控力
    potatowish
        22
    potatowish  
       2023-01-09 10:43:40 +08:00 via iPhone
    看起来他并不太懂 Java ,,有什么理由不用 LocalDate 、LocalDateTime ?
    Jirajine
        23
    Jirajine  
       2023-01-09 11:00:19 +08:00
    我一直认为表示时间值与时区无关,所有时间值都是 UTC 或时间戳,而时区只是对时间值 format 展示时的一项参数。
    littlewing
        24
    littlewing  
       2023-01-09 11:00:53 +08:00
    一律用 uint64_t
    huoshanhui
        25
    huoshanhui  
       2023-01-09 11:29:24 +08:00
    他明白你说的意思,你也知道他不想用。为什么非要强迫他接受呢。
    ikesnowy
        26
    ikesnowy  
       2023-01-09 12:15:02 +08:00   ❤️ 19
    他说得对,他能够为自己的代码负责,而你和微软都不能。

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

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

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

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

    DateTimeOffset: https://github.com/dotnet/runtime/blob/8ccdb1cd29754ed64a451300cd1fc59d35b88d40/src/libraries/System.Private.CoreLib/src/System/DateTimeOffset.cs#L62
    oxromantic
        27
    oxromantic  
       2023-01-09 12:36:03 +08:00
    替换 DateTime 为 DateTimeOffset 的前提是,他的项目有足够高的 test case 覆盖率,否则就是自掘坟墓
    opengps
        28
    opengps  
       2023-01-09 13:05:33 +08:00
    带着要赢的心态对话,自然会血压高的
    dingwen07
        29
    dingwen07  
       2023-01-09 13:35:22 +08:00 via iPhone
    有一说一我都是习惯存 epoch time 来着
    ligiggy
        30
    ligiggy  
       2023-01-09 13:50:33 +08:00
    @opengps 赞同
    wangxiaoaer
        31
    wangxiaoaer  
       2023-01-09 13:56:02 +08:00   ❤️ 1
    如果我是对方,跟题主这样聊也会血压升高,一味的微软建议而又说不出什么实质性优势,而且 2-3 个字甩过来,感觉高冷+不耐烦。
    GTim
        32
    GTim  
       2023-01-09 15:28:36 +08:00
    @dcoder 这个话题又要再来一次么?我以前说用时间戳,被骂的狗血淋头...
    leonshaw
        33
    leonshaw  
       2023-01-09 15:57:44 +08:00
    DateTimeOffset = DateTime + Offset
    本来就是不等价的东西,用在不同场景,哪有什么一个比另一个好?
    nekoneko
        34
    nekoneko  
       2023-01-09 16:17:00 +08:00
    @cubecube #14 redisson + LocalDateTime = 苦痛面具
    securityCoding
        35
    securityCoding  
       2023-01-09 18:50:56 +08:00 via Android
    @GTim 那是他们菜啊
    lbfjkaou
        36
    lbfjkaou  
       2023-01-10 09:39:48 +08:00
    红心怎么点 想赞 ikesnowy 老哥
    anonymous2351d00
        37
    anonymous2351d00  
       2023-01-10 10:21:34 +08:00
    ......什么是时区???
    holouser
        38
    holouser  
       2023-01-10 10:28:18 +08:00   ❤️ 1
    @lbfjkaou 回复 icon 左边,感谢回复者
    hez2010
        39
    hez2010  
       2023-01-10 13:00:37 +08:00
    @Mirana 不知道你在说什么: https://github.com/dotnet/runtime
    lijiji
        40
    lijiji  
       2023-01-10 15:25:57 +08:00
    抛开场景谈建议本身就没什么意义,正如楼上某位 XD 说的,op 和微软根本不用为他的项目负责,当然随便建议。
    对方说得已经很清楚了,效率差距不明显,固件代码重在稳定,抱着书本非要辩赢那当然血压上升
    fighte97
        41
    fighte97  
       2023-01-10 15:50:40 +08:00
    非 geek:能用就别动!
    geek:这个按钮有什么用?
    leeraya
        42
    leeraya  
       2023-01-10 17:05:55 +08:00
    我司时间大部分都是时间戳,前端自己转。
    yuekcc
        43
    yuekcc  
       2023-01-10 23:50:45 +08:00
    情愿后台给我 timestamp ,前台展示折腾时区。后台存个 +08:00 ,然后让前台随用户时区展示,几个意思。
    iseki
        44
    iseki  
       2023-01-23 00:44:20 +08:00
    ??Java 表达时点不是应该使用 Instant 吗,展示的时候再考虑 ZonedDateTime 和 LocalDateTime 啊
    wdwwtzy
        45
    wdwwtzy  
       2023-01-25 12:56:14 +08:00 via iPhone
    @Mirana 那个啥……来源有 10 来年了吧,更新一下大脑吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1420 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 16:35 · PVG 00:35 · LAX 08:35 · JFK 11:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.