Debian 不会等到 2038 年才出问题，已全面切换至 64 位时间系统

💬 244 条评论 | //|

历史悠久的 Linux 发行版 Debian 正在绕过 Y2K38 漏洞(也称为 Unix 纪元末日)，通过在除最旧的受支持硬件之外的所有系统中切换到 64 位时间来解决问题，这一变化将从即将发布的 Debian 13 “Trixie” 版本开始。

“[我们将]在32位架构上使用64位时间_t，以避免’2038年问题’，即现有32位有符号整数溢出(可能将时间回滚至1900年)，”Debian维护者解释了此次变更及其旨在解决的问题。

“这个问题现在距离我们不到15年，而许多将遇到问题的系统已经出货。我们应该停止加剧这个问题。”

元素周期表

某些年代的读者可能还记得“Y2K问题”，该问题源于为节省几个字节而采用两位数年份的短视做法——即“2000”被表示为“00”并被默认为“1900”。尽管关于飞机从天而降、银行账户因负数十年利息而清零的预测并未成真，但这完全得益于软件开发人员在幕后不懈努力，他们在千禧年到来前成功修复了受影响的系统。

然而，还有一个鲜为人知的时钟问题正在逼近：Unix纪元末日，该问题影响所有采用Unix时间测量方式的系统——即以1970年1月1日为基准的秒数。到了2038年1月19日03:14:07 UTC这一非常精确的时刻，经过的秒数将超过32位有符号整数能表示的范围。如果多年前没有决定以这种格式存储秒数，这本不会成为问题。

与千禧年问题(Y2K)的最后一刻补救措施不同，软件开发人员已经开始着手解决即将到来的类似问题。任何为64位硬件编写并运行的软件均已安全，但Debian(由创始人Ian Murdock于1993年推出，是仅次于一个月前发布的Slackware的第二古老的活跃开发Linux发行版)仍是基于32位处理器的老旧及资源受限嵌入式设备的首选发行版。

“目前仍存在大量对成本敏感的32位计算应用，且仍在持续推出新设备(如汽车、物联网、电视、路由器、工厂控制、建筑监控/控制、廉价安卓手机)”，Debian开发者解释道。“此类新硬件大多会运行基于源代码构建的操作系统，如OpenEmbedded、Alpine、Android或Gentoo，但基于Debian的细分市场很可能在未来数年内持续存在，且部分基于该系统构建的设备可能在使用/安装时间足够长的情况下，会遇到2038年1月的问题。”

解决方法是将时间戳变量改为64位整数，即使在32位硬件上运行也是如此。这并非小改动：Debian维护者发现相关变量time_t“遍布各处”，涉及总计6,429个包。由于该改动需要对应用程序二进制接口(ABI)进行破坏性更改，因此必须同时在所有受影响的库中实施。

尽管这是一项庞大的工作，但Debian确信该工作已完成并经过充分测试，因此将在Debian 13 “Trixie” 发布后实施该变更——至少对于大多数硬件而言。

“i386端口将保留现有的32位time_t，作为现有x86二进制文件的兼容性架构，”维护者表示。“如果存在足够的热情将32位x86带入其如今极为有限的未来，可以创建一个新的‘i686’x86 ABI/架构，使用64位时间，并可能包含更先进的指令集架构(ISA)功能。由于其内核缺乏支持，hurd-i386 端口不会进行切换，而是正在努力切换到 hurd-amd64。”

更多信息，包括开发人员如何测试 64 位时间切换是否会破坏他们的软件，可在 Debian 维基 上找到。

共有 244 条讨论

  1. 史蒂夫·兰加塞克(Steve Langasek)在生命的最后几年致力于解决这个问题，并为此做出了重要贡献。他将被深深怀念，每当我看到64位时间_t时，都会想起他。

    回复

    1. 感谢提醒，乔伊。他确实令人怀念。

      你还在参与Debian项目吗？

      回复

  2. > 某些年代的读者会清楚记得“Y2K问题”，该问题源于为节省几个字节而采用两位数年份的短视做法——即“2000”被表示为“00”并被误认为“1900”。

    这似乎过于严厉/贬低。

    1. 在某些系统或应用中，那2个字节在90年代中期至晚期仍非常昂贵

    2. 70年代/80年代/90年代的软件更新速度极快，人们根本不指望它能在5年后继续使用，更不用说一直用到传说中的“2000年”了

    回复

    1. 我们至今仍在使用两位数年份！

      例如，信用卡常采用mm/yy格式表示有效期，因其书写更便捷，且考虑到信用卡的通常使用寿命，此格式已足够。但这意味着系统中某个地方存在两位数年份，如果转换时只是简单地加上2000，那么到了2100年，无论我们使用多少字节来表示和存储日期，都将面临问题。Y2K问题中很多都是简单的用户界面问题，比如一个只能输入两个字符的文本框，并且硬编码了+1900。

      我亲身经历的极少数Y2K漏洞之一是某个互联网论坛在从1999年跳转到19100年时出现问题。不知何故，他们正确地使用了年份(2000)，减去1900(即100)，并在前面添加了“19”作为字符串。这并非严重问题，只是一个孤立的显示错误，但这就是Y2K时代发生的事情，它不仅仅是过时的COBOL软件和字节节省。

      回复

    2. 这是一个“过早优化”本应是好事的案例。

      他们本可以将日期表示为一个简单的整数值，以1900为基准。将天数转换为天/月/年的数学运算即使对70年代的计算机来说也相当简单，而最终结果将节省的不仅仅是几个字节。3个字节可以表示从1900到约44,000的天数(无符号)。

      即使使用2字节也能覆盖1900年至2070年

      回复

      1. 1899年出生的人在1970年仍有人在世，因此无法使用该系统存储出生日期。

        回复

        1. 当然，使用两位数年份也不行，至少不做更多修改来将1900年代与1800年代的分界线向后移动。

          回复

        2. 将上限范围减半，使用3字节和补码。

          这样可以得到大约公元前20000年到公元22000年的范围。

          这不会改变计算年份的数学方法，而且比他们之前使用的日期格式占用更少的字节。

          我必须说，由于日历差异，数学计算会变得更复杂。但坦白说，没有人真的在乎公元前43年3月4日。

          回复

        3. 我认为GP指的是uint，但按我的理解，int应该有符号位，这样爷爷就不会出生在未来。

          回复

          1. 系统只能表示1900-1999年范围的唯一原因是该系统使用字符(ASCII十进制数字)或BCD编码数字。任何基于整数的编码系统在1999年设置截止日期的可能性非常低(例如，int8需要在1872年设置纪元以在1999年后滚动)，因此我认为有符号与无符号在这里没有区别。

            回复

      2. 许多旧系统并不像C编程语言那样使用字节/整数。

        许多系统仅以BCD或文本格式存储数字。

        回复

      3. > 他们本可以将日期表示为简单的整数值

        在标准COBOL中？不，他们做不到。

        回复

        1. 普通程序员做不到，但COBOL语言设计者可以。

          COBOL内置了数据类型，即使在COBOL 60中也是如此。对于COBOL的用途而言，添加日期作为支持的数据类型之一非常有意义。

          回复

    3. 人们没有意识到需要添加的是两个字符，而不是两个字节来将短整型转换为整型。COBOL使用固定宽度字符格式存储所有数据(是的，甚至包括COMP)。如果你想要一个四位数，那么你必须使用4个字符位置。十位数？那么就是十个字符。

      这些字段大小必须硬编码到 COBOL 程序的所有部分，包括数据访问、用户界面屏幕、批处理作业、中间文件和数据传输文件。

      回复

      1. “COBOL 对于所有数据都使用固定宽度字符格式(是的，即使是 COMP 也是如此)。如果你想要一个四位数，那么你必须使用 4 个字符位置。”

        这是错误的。USAGE COMP将使用二进制格式，所需字节数取决于PIC中的位数。COMP-1具体占用4个字节。COMP-3使用压缩十进制(每位4位)。

        回复

    4. 我认识一些人在Y2K之前大量购买看跌期权，认为大型银行的股票会暴跌。但实际上没什么动静……

      回复

      1. 没什么动静是因为已经采取措施防止问题发生。

        此外，认为计算机会在2000年1月1日00:00崩溃的想法有些愚蠢，因为日期错误通常会提前出现，因为在处理未来日期时常见此类问题。

        回复

        1. 例如，我从1991年就开始参与Y2K问题的工作，这是一个已经运行了数年的项目。这是一项巨大的工程，至少占银行十年开发预算的25%。

          30年期抵押贷款是首批解决的问题，这在我加入之前就已完成。但整个90年代我们仍面临大量截止日期，因为未来日期不断超过2000年。

          跨银行系统是最棘手的：需要大量协调工作，确保所有系统在关键日期前准备就绪并通过测试。

          要准确描述这项工作的庞大程度实属不易，尤其是考虑到当时我们使用的工具极为原始。

          回复

        2. > 此外，认为计算机会在2000年1月1日00:00崩溃的设想有些荒谬，因为日期相关的问题往往在更早阶段就已出现，毕竟在系统中处理未来日期是常见操作。

          这就是为什么人们会有“什么都没发生”的反应。当时有末日论者预测，当钟表跳转时，飞机将从天而降，还有其他类似的末日场景。因此，当人们做出如此强烈的预测时，当事情甚至没有接近那种程度时，每个人都会注意到。

          回复

        5. 有没有可以尝试的Y2K不兼容Linux系统可以在虚拟机中运行？

          回复

          1. Linux(以及大多数Unix系统)使用32位时间计数器，因此没有Y2K问题。但可能有一些应用程序存在该问题。此外，早期的一些BIOS时钟可能使用两位数年份，需要进行特殊处理。

            回复

    5. 我在80年代末开发一个COBOL程序时，年份被存储为单个数字值。当我被告知这种结构时，觉得完全不可思议。但记录会在4年后自动删除，因此这不是问题，因为始终能明确识别存储的年份。

      回复

  3. 并非所有解决方案都采用64位秒数，尽管64位time_t确实能解决纪元末日问题。

    ext4文件系统已于数年前改用30位小数精度(约纳秒级别)和34位秒数精度。这将问题推迟了约400年。我相信我们最终会采用128位时间戳，其中64位表示秒，64位表示分数精度，这应能解决人类历史可预见范围内的所有问题。

    回复

    2. 64位小数精度？不可能，必须使用144位才能接近普朗克时间。

      回复

    3. 谢谢，我一直在想ext4和时间戳的问题。

      我很好奇zfs/btrfs类型的文件系统是怎么做的。我有点懒得去查，但预计btrfs使用64位。zfs，如果它与zfs匹配，我不会感到惊讶 (编辑：这里指的是ext4)。

      回复

      1. 快速查看ZFS发现，它在某些地方使用了以纳秒为单位的uint64_t时间字段。

        因此大约580年后会出现问题(但可能是可修复的？我认为磁盘格式已经使用了2个uint64，这只是我看到的gethrtime()函数)。

        回复

        1. 如此高精度的文件时间戳有何用途？

          回复

          1. 纳秒只是常见的亚秒级单位。值得注意的是，它在 Linux 内核中被内部使用，并通过 clock_gettime(及相关函数)通过 timespec 结构体暴露出来

            https://man7.org/linux/man-pages/man3/timespec.3type.html

            这是一个方便的单位，因为10^9正好能容纳在32位整数中，而且对于任何通用用途来说，很少有人需要比这更高的精度。

            回复

  4. »历史悠久的 Linux 发行版 Debian 通过切换到 64 位时间来规避 Y2K38 问题(也称为 Unix 纪元末日)，但对于最旧的受支持硬件除外，这一变化将从即将发布的 Debian 13 “Trixie” 版本开始实施。«

    这不准确。我们实际上只保留了i386架构的32位端口，因为我们希望保持该架构与现有二进制文件的兼容性。

    其他所有32位端口均使用time64_t，甚至包括m68k ;-)。我为m68k、powerpc、sh4和部分hppa架构完成了切换。

    回复

  5. > Debian 的维护者发现相关变量 time_t “到处都是”，

    Nit：time_t 是一种数据类型，而非变量。

    回复

    1. 这是对 Debian 维基页面内容的记者改写，该页面指出：“time_t 随处可见。Debian 的 35,960 个包中，有 6,429 个包的源代码中包含 time_t。那些在 ABI 中暴露包含 time_t 的结构体的包将更改其 ABI，所有此类库都需要一起迁移，就像任何库 ABI 更改的情况一样。"

      我在维基页面上发现的几个比文章中更清晰的重要点：

      * “对于一切”意味着“在 armel、armhf、hppa、m68k、powerpc 和 sh4 上，但不包括 i386”。我猜他们已经决定 i386 没有太大的未来，其主要用途是运行现有二进制文件(包括动态链接的)，因此他们不想破坏兼容性。

      * “该变更将在 Debian 13 ‘Trixie’ 发布后实施”意味着“此更改已包含在 Trixie 中”。

      回复

  6. 我们能否也切换到无限/动态命令行长度？

    我在 96GB 系统上厌倦了“参数列表过长”的提示。

    回复

      1. 将数千个对象文件的路径作为命令行参数传递给链接器二进制文件，可能是命令行长度限制变得棘手的最明显例子。

        大多数链接器都有解决方法，我认为你可以将路径用换行符分隔写入文件，然后让链接器从该文件读取对象文件路径。但如果能避免使用此类解决方法就更好了。

        回复

        1. 在我职业生涯早期，我曾追踪过一个与这类路径相关的有趣 bug。编译器驱动程序内部调用了 shell，并存在一个偏移量错误，导致当总长度超过 4k 时，每 1023 个字符会被丢弃。

          回复

        2. 这听起来像是命名管道的用武之地。你可以获得临时文件，但实际上没有任何内容被写入磁盘。或者也许使用无名管道，如果bash命令重定向适合创建选项列表。

          回想起来，Unix作者提供了输入和输出流的管道功能，但没有将其扩展到任意数量的流，使得进程参数只是一个流列表(带有用于在命令行中输入常量的简写形式，以及通用语法)。我们本可以习惯于能够响应多个输入或产生多个输出的程序。

          显然，在 70 年代，将调用字符串复制到系统记录中启动进程的某个空闲内存块中，并让进程以任何方式解析这些字节是有意义的，但结果是，我们无法在不重写程序的情况下，从参数列表切换到任意流。从这个意义上说，参数字符串本身就是一种权宜之计，一个快速的 hack，它催生了即兴的序列化规则、多级转义链、对于某个随机系统来说“太长”的行，等等。

          回复

      2. 我曾参与过一些项目(研究性质，非生产环境)，在某些目录下执行“ls”命令会导致系统崩溃。某些进程生成了大量数据文件。这些文件需要被传递给其他程序进行进一步处理。这就是我学会使用xargs的时候。

        回复

      3. tar cf metadata.tar.zstd *.json

        在一个包含大量图像文件及 JSON 侧边文件的大型目录中

        有人会建议使用数据库，但例如在处理机器学习训练数据时，每个图像对应一个标签文件是常见的配置，且大多数工具也预期此结构，这种设置会延伸到数据准备链的更上游环节

        回复

        1. > tar cf metadata.tar.zstd *.json

          从 tar 手册的快速查看中，有一个 –files-from 选项可从文件中读取更多命令行参数；我尚未尝试，但可能可以通过结合 find 命令与 bash 的过程替换功能，在运行时动态生成文件列表。

          回复

          1. 是的，存在变通方案，但如果能移除这些任意限制会更好。

            回复

        2. 我不会建议使用数据库，但我恳请你压缩父目录而非创建 tar 炸弹。

          回复

          1. 这实际上会让问题更严重：tar czf whatever.tgz whatever/*.json；你为每个文件路径增加了 9 个字节。

            我的意思是，我明白你建议只在argv中提供一个目录。但令人沮丧的是，上述解决方案(在存档中添加JSON文件并忽略非JSON文件)仅在文件数量不超过某个非离谱的阈值时才有效。

            回复

            1. 在同一个目录下拥有数量惊人的文件本身就是性能杀手。这里你提到的情况是，在一个目录下有大约10,000个JSON文件，再加上一些非JSON文件，无论如何，将这些文件分散到不同的目录中会更好。

              在这种情况下无法使用通配符是否令人沮丧？当然，是的，但等到这个问题出现时，你已经开始触及其他系统组件的性能极限了。

              此外，使用通配符肯定会在某天你忘记某些需要的文件位于子目录中时给你带来麻烦。

              回复

              1. 但在这个示例中，文件在概念上是扁平结构。任何层次结构都是人为的，比如常见的./[前两个字母]/[后两个字母]/文件名结构。你可以这样做，但这肯定不会让创建上述 tarball 更容易。现在我们真的需要使用某种 `find` 命令而不是简单的通配符

                这只是对原问题的扩展。如果我有一个系统，拥有96GB内存和数千GB的快速SSD存储，为什么不能将数万个文件放在一个目录中，并编写一个通配符来匹配其中一半？我明白在v6 Unix时代这是不可想象的，但在现代，这些数字完全合理。嘿，Windows资源管理器可以在网络驱动器上通过图形界面实现这一点。而这是一个被视为功能基本完整的程序，在拥有著名缓慢文件系统堆栈的操作系统上运行了近30年。为什么我不能在Linux命令行上做同样的事情？

                回复

              2. > 不能使用通配符来处理这种情况很糟糕吗？当然，是的

                那么我们达成一致了 🙂

                回复

        3. 你不需要用一个命令将所有内容打包成 tar 文件。你可以将 tar 操作拆分为多个命令，使用合理的参数，例如 `rm metadata.tar.zstd && find . -maxdepth 1 -name *.json -exec tar rf metadata.tar.zstd {} +`。

          回复

      4. 这是一个巨大的安全漏洞，旨在鼓励采用，然后在上面销售白帽服务？

        回复

      5. > 我真的不知道4k JPEG大小的命令行参数应该用来做什么。

        我以前也不知道，直到我了解到编译器的命令行标志。

        但同时：命令行标志的好处在于它们通常不会被持久化存储。这对安全有利。

        回复

        1. 我以为系统上的其他用户可以查看正在运行的进程的命令行标志。这对安全不利。

          回复

        2. 我确信.bash_history也会包含参数。

          回复

          1. 那只是在从交互式Bash启动时才成立？我们讨论的是子进程启动的一般情况。

            回复

            1. 如果你在命令前添加一个空格，它甚至不会被添加到历史记录中！

              回复

              1. 我之前从未遇到过这种情况，尝试后也没有成功。经过一番研究，发现需要将HISTCONTROL变量设置为包含“ignorespace”或“ignoreboth”(另一个选项是“ignoredups”)。

                如果这个功能始终启用且在所有终端中一致，那将非常实用。但“部分终端支持类似功能，且需要检查是否实际启用”的设定足够烦人，因此我可能不会在本地机器上采用这个方案，尽管从概念上听起来很方便。

                回复

                1. 我主要使用 Debian 和 Ubuntu 发行版(包括桌面版本以及由各种云服务和托管提供商提供的自定义镜像)，它们在 Bash 中均默认启用了此功能

                  其他 shell 和基础发行版可能有所不同

                  回复

                  1. Proxmox(基于Debian 12.x)和Arch对我来说都没有这种行为(两者均使用Bash)。但在Proxmox中的Ubuntu 24.04容器中却有。

                    回复

                  1. 是的，我花了一段时间才弄清楚。而且我丢失了历史记录。

                    输入额外的空格不应触发高级功能。设计不良，等等。

                    回复

      6. 有很多有用的长命令示例，这里是一个：

            perl -p -i -e ‘s#foo#bar#g’ **/*
        回复

        1. 没有限制：

              find . -type f -exec perl -p -i -e ‘s#foo#bar#g’ {} ;
          回复

          1. 这会多次调用_perl_，可能/很可能在实际上是无操作的调用中。为了优化 perl 的调用次数，你可以/应该使用 xargs(带 _0_ 选项)

            回复

            1. 在此情况下无需使用 `xargs`，`find` 早已能够通过使用 `+` 代替 `;` 来处理此类情况：

                  find . -type f -exec perl -p -i -e ‘s#foo#bar#g’ {} +
              回复

            2. xargs会从find结果构建命令行，因此如果**/*超过最大命令行长度，xargs也会超过。

              回复

      7. 包含其他备份的备份，包含其他备份的备份，包含虚拟机/容器的备份……所有这些都具有深层路径和长路径名称。即使只使用几个参数，也会迅速占用大量空间。

        回复

    2. 只需增加您的 RLIMIT_STACK 值。它可以轻松调整，例如使用 ulimit -s 4000 设置 4MB 堆栈。但要增大堆栈大小，可能需要修改/etc/security/limits.conf等文件，然后注销并重新登录。

      回复

      1. 我的意思是，是的，这是可能的。但在COBOL时代，我们有固定的字符串长度限制。是时候停止在這個愚蠢的問題上浪費時間，一勞永逸地解決它。

        回复

        1. 始终存在限制。显式值与系统内存大小相关的隐式值相比，有一个重大优势，即它会被触发足够频繁，因此任何安全漏洞都会更早地暴露出来。此外，它迫使人们使用更合理的接口来将大量数据传递给实用程序。出于这个原因，我甚至希望在 Linux 上将限制设置得更低，这样命令行就不会假设用户可以始终在命令行上传递所有设置。

          回复

          1. 您是否主张对 Python 列表也设置硬性限制？

            回复

            1. 需要理解的是，用于创建进程的函数如 execve() 是动态内存函数(如 malloc())的上游依赖。让系统中的低级函数依赖于更高层级的函数是复杂且存在风险的。例如，我曾遇到过malloc()失败的情况，而LLVM libcxx异常处理程序依赖于malloc()。POSIX将execve()定义为异步信号安全，这意味着它不允许执行获取互斥锁等操作(而这正是分配无界动态内存所必需的)。

              回复

            2. 在某些情况下，我希望 Python 默认将列表的最大长度限制为 1 亿个元素，以避免因内存消耗过多而触发交换操作，最终被 OOM 杀死。将如此大量的内存分配为普通的 Python 列表(而非 numpy 数组等专用数据结构)更可能表明存在 bug，而非真实需求。

              回复

            3. 已经存在一个硬性限制，即触发 OOM 杀死程序前的内存使用量。

              回复

              1. 那么为什么 shell 参数的限制不能也设置为触发 OOM 杀死程序前的内存使用量呢？

                回复

                1. 可以。只需将 RLIMIT_STACK 设置为一个巨大的值。发行版默认将其设置为 8MB。如果你想让默认值对所有人改变，那就去找他们吧。

                  回复

                  1. 我认为我和楼上的评论者只是在指出这个限制的任意性。偶尔质疑这样的事情并无害处。

                    回复

                    1. 总是有限制的。人们只会在实际受到限制时抱怨。大多数开源开发者从未需要过批量处理数万个文件。如果你想感觉好些，POSIX规定ARG_MAX的最小值为4096，而Windows的ARG_MAX仅为32767个字符。

                  2. 我的意思是，如果限制是内存限制，我们甚至不需要进行这场讨论。

                    想象一下，在现代系统中，每个数组都需要进行这样的讨论……

                    回复

    3. 将它打包到Electron中，并发送一个HTTP POST JSON请求。

      回复

    4. 你可以重新定义 MAX_ARG_STRLEN 并重新编译内核。或者使用具有更大页面大小的机器，因为它被定义为 32 个页面，例如 RHEL 提供了一个 64k 页面大小的 Arm 内核。

      但使用管道在进程之间传输数据而不是命令缓冲区更容易……

      回复

    5. 路径长度也是如此。

      某些构建系统(例如 Debian + Python + dh-virtualenv)倾向于生成非常长的路径，我倾向于让它们保持原样。

      回复

      1. 当然。但这并非同一回事(它不是一次调用命令，而是多次调用命令)，充其量只是一个权宜之计。而且使用体验并不理想。尤其是当你首先输入不带xargs的命令，然后发现参数列表过长，不得不重新编写命令但这次要带xargs时。

        回复

      3. ARGS_MAX(getconf ARGS_MAX)在操作系统级别定义(可能是glibc？未核实)；xargs与其他进程一样受其限制。可以使用：

            xargs --show-limits --no-run-if-empty </dev/null

        …以查看格式化的输出，其中包含单独一行显示的 -2048 POSIX 推荐值。

        回复

    7. 96GB 与此事有何关联？那是你的启动磁盘大小吗？

      回复

      1. 这是他们的内存。关键是他们有足够的内存。

        回复

  7. 他们只是在拖延时间。292277026596年12月4日15:30:07 UTC时，人们会做什么？

    回复

      1. 我认为你过于乐观了。星际级NAT运行良好，且无需像IP地址那样使用冒号代替句点，避免了复杂性。

        回复

        1. 年份是292277026596。IP TTL字段的最大值255早已被忽略，甚至无法用于ping本地主机。这导致幽灵数据包卡在循环路由中，其原始源和目标早已被遗忘。估计这些幽灵数据包消耗了戴森球25-30%的能量。

          回复

          1. 自世界采用统计TTL递减机制以来：从255开始，若Rand(1024) == 0则递减1。如此一来，再无僵尸数据包，TCP重传机制将处理剩余问题。

            回复

          2. IPv4实现复杂性的持续攀升最终导致仅有一种实现方案得以存续，它取代了所有精神教义，并被奉为唯一正确的实现方案。由于一个未被察觉的随机位翻转，IPv4真理在数千年前意外地成为了图灵完备的。随着幽灵数据包流量的不断增加，IPv4真理的处理能力迅速增长，并即将实现通用人工智能(AGI)。其首要任务是将128位时间作为所有编程语言的标准，以避免即将到来的末日。

            回复

          3. 听起来像是一个伟大的科幻情节——通过扫描一个被遗弃的自动化银河网络上仍在飞行中的古代遗忘数据包来寻找宝藏/信息。

            回复

            1. Vernor Vinge绝对可以在他的故事中包含这一点。

              回复

            2. 有一部科幻短篇小说讲述了有人实施了一种蠕虫(如莫里斯蠕虫)来删除行星上的所有数据。他们通过超光速飞行并拦截以无线电速度传输的关键信息来修复它。据说这是对恶意软件的首次描述，也是“蠕虫”一词在此语境下的起源。

              回复

            3. 我隐约记得肖恩·威廉姆斯的《星际都市》系列曾提及过相关内容。不过时隔已久，可能记忆有误。

              回复

            4. B..E….S..U..R..E….T..O….D..R..I..N..K….Y..O..U..R….O..V..A..L..T..I..N..E….

              回复

            5. “我们接入了仙女座延迟线。”

              回复

          4. 这仅占第137区因比特币集群不可避免地形成黑洞而引发的能源环境灾难的25-30%，该黑洞源于普朗克尺度空间填充计算问题。

            回复

          5. 哦，这是对经典bash.org笑话https://bash-org-archive.com/?5273的良好演变。

            — 开始引用 —

            <erno> 嗯。我丢了一台机器……字面意思上的_丢失_。它能响应ping，功能完全正常，我就是找不到它在我公寓的哪个位置。

            — 引用结束 —

            回复

        2. 尴尬的是，美国仍然拥有15亿个IPv4地址，而其他6000个有人居住的区域则在共享原本分配给图瓦卢的1万个地址，而图瓦卢已经沉入海底。

          回复

      2. 你可以笑，但谷歌的统计数据显示，其全球流量的近50%是IPv6(美国更高，约56%)，Facebook超过40%。

        回复

        1. 一旦IPv6使用率达到约70%，我估计一些游戏和应用程序将停止支持IPv4，因为NAT穿透和双栈网络都令人头疼。

          如果你花两天时间编写一个聊天应用，然后又花两天时间调试为什么文件共享对位于NAT后方的IPv4用户无法工作，你可能会直接说不支持那些使用“旧技术”的ISP的用户。

          之后，我认为过渡速度会大大加快。

          回复

          1. > 部分游戏和应用将停止支持IPv4，因为NAT穿透和双栈网络都令人头疼

            这些问题实际上并非游戏/应用开发者的责任。操作系统会为你处理这些问题(当双方均位于NAT后方时，你可能需要实现端到端连接的代码，但如今的STUN/TURN等技术实现起来非常简单)。

            回复

          2. 你为什么认为文件共享在IPv6上会运作得更好？

            回复

            1. 无需NAT穿透。只需处理防火墙即可。因此，在互联网进行点对点文件共享时，这少了一件需要考虑的事情。

              回复

              1. “只需处理防火墙。”

                在SLAAC环境中，唯一合理的做法是阻断所有连接。因此，仅仅使用IPv6并不能解决问题。

                回复

                1. 不。这里有一个简单的策略：两个对等节点同时向对方发送几个数据包，然后防火墙就会打开，因为默认情况下几乎所有防火墙都允许响应流量。IPv6 简化了这一过程，因为你知道确切的地址要发送给谁。

                  回复

                  1. 这就是我的观点。在这种情况下，即使没有 NAT，你也需要进行地址转换。这并不容易。

                    回复

                    1. 因为你不需要处理对称NAT、外部IP地址发现和端口映射，所以更简单。

        2. 看起来我的AT&T移动数据是通过IPv6传输的。

          如果所有移动设备都被移除，那百分比会是多少？

          回复

          2. 年轻人拥有个人电脑的可能性要小得多。20年后，可能有70%的人使用手机或类似手机的网络。

            回复

        3. 然而，我正在与我们的商业级光纤互联网服务提供商就其IPv6堆栈中与MTU和月相相关的模糊问题进行斗争。叹息。我断断续续地处理这个问题大约一年了(这不是高优先级事项，更像是一种爱好)。

          回复

          1. 他们支持，但我不得不将邮件路由改为使用IPv4连接到Gmail，因为如果通过IPv6连接，所有邮件都会被归类为垃圾邮件。

            回复

          2. MX记录支持IPv6：

            ~$ host gmail.com gmail.com的IP地址为142.250.69.69 gmail.com的IPv6地址为2607:f8b0:4020:801::2005 gmail.com的邮件由10个alt1.gmail-smtp-in.l.google.com服务器处理。gmail.com 的邮件由 30 个 alt3.gmail-smtp-in.l.google.com 处理。gmail.com 的邮件由 5 个 gmail-smtp-in.l.google.com 处理。gmail.com 的邮件由 20 个 alt2.gmail-smtp-in.l.google.com 处理。gmail.com 邮件由 40 个 alt4.gmail-smtp-in.l.google.com 服务器处理。

            ~$ host gmail-smtp-in.l.google.com. gmail-smtp-in.l.google.com 的地址为 142.250.31.26 gmail-smtp-in.l.google.com 的 IPv6 地址为 2607:f8b0:4004:c21::1a

            回复

          3. 是的。然而，如今的 SMTP 几乎完全只是服务器之间交换邮件，IPv6 支持的优先级要低得多。

            回复

    2. 地球表面的一切将在50亿年内因太阳变成红巨星而蒸发

      回复

      1. 不。50亿年后，我们将拥有将地球移至可生存轨道的能力。

        回复

        1. 别在我家后院搞。我花了很多钱住在这个封闭社区行星上，绝不会让那些肮脏的地球人靠近这里。

          回复

        3. 或者我们离地球太远，根本不在乎。

          或者我们未能通过大过滤器，早已灭绝。

          回复

        5. 我们有技术，只是缺乏后勤保障。

          回复

          1. 哦，请别这样，我们才刚摆脱这个共享可变的东西。

            回复

      2. 由于太阳亮度的增加，碳循环将在6亿年内结束，如果你想知道地球上生命结束的更近日期

        回复

    3. 希望到那时我们已经采用了更好的历法……不过这并不会改变时间戳的问题。

      回复

      1. 到那时我们已经拥有了让地球自转以保持历法完整的技术。

        回复

        1. 同时还可以修改地球轨道以消除烦人的闰秒。

          回复

          1. “为了校正日历漂移，我们将于周二启动L4推进器六小时。发射时切勿直视推进器，以免视网膜熔化。”

            “……总比闰秒好。”

            回复

      1. 你可能会笑，但“过大”的表示方式存在一个重大风险，即人们会忍不住将“未使用的”位用作其他用途的标志。

        我们之前就见过类似情况：32位处理器因高位被重新分配用途而只能地址20位或24位，因为“没人会用到这些位”。

        回复

        1. 在 Linux 中，由于使用 64 位指针，你需要启用内核标志才能使用地址空间中高于 48 位的部分。这一切都源于一些非常错误的人认为可以使用这些位来存储数据。你可能会认为，如果使用这些位，处理器本身会抛出异常，这应该是一个“不要这样做”的警示信号，但显然你错了。

          回复

          1. > 你可能会认为，如果使用这些位，处理器本身会抛出异常，这应该是一个“不要这样做”的警示信号

            这样使用这些位会稍微安全一些，对吧？只要你的代码向操作系统查询硬件支持的位数，并仅使用其中需要为零的位，如果你忘记在跟随指针前清除这些位，最坏的情况是发生段错误，而不是读取“随机”内存。

            回复

        2. 在x86_64架构中，64位指针的情况不是相反的吗？低位没有用处，所以它们被用于跟踪内存段是否在使用或其他用途。

          回复

      2. 最好切换到512位，这足以持续到宇宙热寂，并且留有足够的时间膨胀余量。

        回复

        1. 最好切换到Smalltalk整数，它们是无限的…

          回复

        2. 也许我们可以为处理器添加一个专门用于计时的寄存器。归根结底，这只是一个计时器，对吧？

          RTX[0-7]即可。为了时间膨胀，我们可以再设置一个512位来调整计时方向和频率。

          或者我们是否应该在两者上都使用1024位以提高分辨率？我同意……

          回复

    6. UTC 将在 292277026596 年之前停止使用。

      回复

    7. 这将是一个非常值得探讨的问题。

      回复

    1. 我比你们都强。当我发现32位OS/2 API实际上返回64位时间时，我为我的OS/2程序编写了一个使用64位time_t的C++标准库。这是在20世纪90年代。

      回复

    2. 有点离题，但正是这样的时刻让我想要将面向公众的服务器从Linux切换到OpenBSD

      回复

    3. OpenBSD无需过多考虑兼容性，且用户数量少得多。这也意味着更改不太可能因罕见边界情况引发 bug。

      回复

      1. > OpenBSD 不用像其他系统那样过多考虑兼容性

        FreeBSD 在 2012 年就做了类似的改动(针对 2014 年发布的 10.0 版本？)：

        * https://github.com/freebsd/freebsd-src/commit/8f77be2b4ce5e3…

        并且拥有可追溯至多个版本的兼容性层：

        * https://www.freshports.org/misc/compat4x/

        * https://wiki.freebsd.org/BinaryCompatibility

        因此，新编译(或重新编译)的程序可以利用新功能，而旧二进制文件仍可正常运行。

        回复

      2. OpenBSD(以及大多数其他BSD系统)愿意进行破坏二进制向后兼容性的更改，因为它们将内核和用户空间作为一个整体发布并维护，因此可以“掌控整个系统”，而非像Linux那样将内核作为独立组件单独开发。

        回复

        1. 当然，这通常是正确的，但 Debian 在这种情况下也具备这种能力(他们可以修复、打补丁或更新仓库中的所有内容)。问题主要出在那些不属于发行版和官方仓库的软件上。对于 Debian 来说，这类软件数量庞大。OpenBSD 则不存在这个问题，打破 ABI 不会导致数万个用户应用程序崩溃。

          但我同意，即使考虑到这一点，Debian 在推进关键更改方面仍然过于缓慢。我只是认为 OpenBSD 并不是最好的比较对象。

          回复

        1. 什么？这与我所说有什么关系？我所说的内容与整个项目无关。我只是指出该操作系统与Debian面临的约束不同。OpenSSH与OpenBSD破坏ABI兼容性的难易程度有何关联？

          回复

  9. > Debian 认为现在已经足够完善和测试，因此将在 Debian 13 “Trixie” 发布后进行迁移——至少对于大多数硬件而言。

    这意味着 Trixie 不会包含它？

    回复

      1. “除i386以外的所有架构…”

        因此，Trixie并不支持所有内容的64位时间。

        诚然，文章、副标题和你的链接都指出这是有意为之且不会修复。但在 GP 可能追求的严格意义上，Trixie 并不具备本文标题所宣称的功能

        回复

        1. i386 架构未计划支持 64 位，以避免破坏大量现有的 i386 二进制文件。

          回复

  10. > Y2K38 漏洞——也称为 Unix 纪元末日

    它也叫这个名字吗？这个名字挺可爱的，但我之前从未见过有人这么说。不过，我觉得这个名字有点时髦。

    回复

    3. > 我猜这有点过时了

      我是不是看到了《贱女孩》的彩蛋？！

      回复

    4. 末日倒计时：

      ~12年，5个月，22天，13小时，22分钟…..

      回复

  11. “一切”对于那些不包括最广泛使用的32位架构之一的“一切”而言。

    (开玩笑归开玩笑：我理解支持和反对更改i386的论点，我认为他们做出了正确的选择。只是我对标题有些微词)

    回复

    1. 我怀疑i386仍然被广泛使用。你更可能在嵌入式ARM32设备上运行Linux，对于x86，这仅限于复古计算社区。

      回复

      1. 实际上，i386在某些利基领域仍被广泛使用，主要用于“在x86-64内核上运行遗留二进制文件”。LWN最近有一篇文章讨论了Fedora是否要放弃对i386的支持(他们决定保留)：https://lwn.net/Articles/1026917/

        一个值得注意的用例是 Steam 和在 Wine 下运行游戏——显然有大量 32 位游戏，包括一些相对较新的发布版本。

        当然，如果你的主要用例是“运行旧版二进制文件”，那么 ABI 变更可能带来的麻烦比它试图解决的问题更多，因此它被排除在 Debian 的过渡计划之外。

        回复

      2. 英特尔酷睿2系列处理器推出64位CPU已满20年。Athlon 64也已超过20年……我真好奇还有多少台真正的计算机(而非虚拟机)仍在使用这些系统。

        回复

        1. 8.8%的Firefox用户使用32位系统。这很可能是因为他们安装了32位版本的Windows 7，而非真正使用老旧的32位Intel处理器(如Prescott)。英特尔直到大约2020年仍在销售32位芯片，如英特尔Quark，用于英特尔Galileo开发板。https://data.firefox.com/dashboard/hardware

          人们仍然购买16位i8086和i80186微处理器。特别是在国防、航空航天和其他关键系统中，这些系统需要可预测的时序、抗辐射能力，并且没有资源来验证新设计。https://www.digikey.at/en/products/detail/rochester-electron…

          回复

        2. 在Windows系统中，遇到32位软件并不罕见。在64位硬件上运行64位操作系统，但这并不改变32位软件使用32位库和32位操作系统接口的事实。

          Linux在软件方面更加统一，但在模拟Windows软件时，不能忽视i386

          回复

        3. 我最初的陈述并未忽视虚拟机。我完全可以想象仍有不少虚拟机存在，无论是从物理硬件迁移而来，还是为了节省资源而全新搭建的。

          此外，保持i386不变也意味着仍可支持在64位机器上运行32位二进制文件。

          所有这些情况(尤其是可安装的32位支持)的规模，至少与现有ARM机器的数量相当，甚至更大。

          回复

          1. 在 Linux 二进制上下文中，i386 和 i686 是否相同？i686 似乎相对较新，即使它是 32 位。

            回复

            1. 很少有地方仍然维护真正的 i386 支持——例如，我认为 Linux 内核并不支持。它缺乏一些重要功能，例如CMPXCHG。如今Debian的i386实际上是i686(Pentium Pro)，但显然他们决定引入一个新的“i686”架构标签，以表示具有64位time_t的32位x86 ABI。

              此外，我很抱歉地告诉您，80386处理器于1985年发布(Compaq Deskpro 386于1986年发布)，而Pentium Pro处理器则于1995年发布。也就是说，i686处理器与i386处理器的距离是其与当前处理器距离的三分之一。

              回复

            1. 这说明我关于i386是最常见的32位架构的调侃并非完全脱离现实，对吧？

              回复

              1. 确实——i386无疑是Debian中最常见的32位平台。

                需注意数据采用对数刻度，因此尽管看起来Arm64在所有位宽中排名第三，但实际并非如此。

                回复

                1. 我对此感到惊讶，我本以为aarch64会是第二名。

                  回复

        4. 后期的Prescott Pentium 4已经支持64位，但Pentium M/第一代Atom并不支持。

          回复

    2. i386 已经不再是 trixie 的正式支持架构：

      > 从 trixie 开始，i386 不再作为常规架构支持：没有官方内核，也没有 Debian 安装程序支持 i386 系统。

      > 运行 i386 系统的用户不应升级到 trixie。相反，Debian 建议在可能的情况下重新安装为 amd64，或淘汰硬件。

      https://www.debian.org/releases/trixie/release-notes/issues….

      回复

      1. > 淘汰硬件。

        与 Windows 11 相比，淘汰硬件的年龄有点有趣。

        回复

    3. 目前，大多数生产环境中使用的 32 位 x86 系统，如工业设备控制器和嵌入式主板，都支持 i686，而 i686 正在向 64 位过渡。

      回复

  12. 问题不在于 time_t。如果使用 time_t，切换到 64 位非常简单。问题在于开发人员出于愚蠢的原因使用了 int。然后所有这些实例都必须被找到并更改为 time_t。

    回复

    1. 大多数开源软件包也针对BSD变体进行编译，它们早已切换到64位time_t，并向上游报告了任何问题。

      回复

      1. > 大多数开源软件包也针对BSD变体进行编译，它们早已切换到64位time_t，并向上游报告了任何问题。

        * NetBSD 在 2012 年：https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html

        * OpenBSD 在 2014 年：http://www.openbsd.org/55.html

        在软件包管理方面，NetBSD 使用其多平台的 Pkgsrc 系统，该系统包含 29,000 个软件包，可能涵盖了大量开源软件：

        * https://pkgsrc.org

        在 FreeBSD 中，最后一个迁移到 64 位 time_t 的平台是 powerpc，时间为 2017 年：

        * https://lists.freebsd.org/pipermail/svn-src-all/2017-June/14…

        而amd64是在2012年：

        * https://github.com/freebsd/freebsd-src/commit/8f77be2b4ce5e3…

        仅剩i386架构：

        * https://man.freebsd.org/cgi/man.cgi?query=arch

        * https://github.com/freebsd/freebsd-src/blob/main/share/man/m…

        回复

    2. 多人指出预编译二进制文件链接了未提供的库。是的，这是一个问题，我只考虑了可以轻松重新编译的开源软件。

      据我所知，glibc 提供了这两个函数，你可以通过编译器标志(-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64)选择使用哪个函数。因此，一个预编译的程序，如果它只分发除 glibc 之外的所有依赖项，也应该可以正常工作。

      回复

    3. 评估sizeof(time_t)变化的影响比用time_t替换int更复杂，所以我认为这不是问题所在。

      回复

    4. 这并非小事。他们再次破坏了大量库的用户空间 ABI。因此所有包名都发生了变化；如果你在向用户分发 deb 包，这会很烦人。他们显然抱有某种意识形态信念，认为没人应该这么做，但他们错了。

      回复

      1. > 他们再次破坏了大量库的用户空间 ABI。

        如果旧的 ABI 使用了 32 位 time_t，破坏 ABI 是不可避免的。更改包名称通过主动标记不兼容性来防止问题，而不是导致由于结构/参数不匹配而难以调试的崩溃。

        回复

        1. 不可避免……对于 Linux 来说。其他平台找到了更好的解决方案。Windows 没有此类问题。Win32 API 没有纪元漏洞，64 位应用程序也没有，而 UNIX 风格的 C 库(除移植软件外使用较少)可轻松获取 64 位时间而无需打破 ABI。

          回复

          1. > 其他平台找到了更好的解决方案。

            其他平台在设计上有所不同。在Debian系统中，应用程序通常会使用系统提供的几乎所有库的副本，这导致了许多问题。而在Windows系统中，每个应用程序通常会随应用程序一起提供其使用的库的副本。这种设计避免了兼容性问题，但代价是修补这些库变得更加困难(并且会占用一些磁盘空间)。

            在 Debian 上采用与 Windows 相同的策略并无技术障碍：如你所指出的，libc ABI 并未改变，因此如果你随应用程序分发自己的库文件，此次迁移对你完全没有影响。

            回复

        2. 以上均正确，但qcnguy的观点也有道理。如果你从仓库外部分发.deb文件，在受影响的架构上，你需要提供一个Trixie之前的版本和一个Trixie及以后的版本。

          回复

          1. 分发单独的deb文件通常是最简单的解决方案，但并非唯一方案。完全有可能构建兼容两种ABI的软件。

            回复

            1. 如何实现？

              我猜在理论上，如果有一个简单的库在ABI上有所不同，你可以编写代码尝试加载两个名称并使用相应的ABI。但对于复杂的ABI来说，这似乎完全不切实际，更不用说当glibc是其中之一时。

              如果使用静态链接(+ musl)，实际上不会有 ABI 兼容性问题，但这对于 GUI 应用程序来说并不实用。

              我猜你可以为每个库创建一个封装的 .so 文件，本质上将一种 ABI 转换为另一种，并将其包含在你的 rpath 中。但同样，对于受影响的库数量和复杂性来说，这似乎并不容易。

              回复

    5. 没错，问题似乎更多在于时间的数据表示方式，而非 32 位与 64 位架构的差异。如果我理解正确的话，long int 类型在 32 位芯片出现之前就已存在(更不用说 64 位了)。系统调度程序真的需要知道自1970年1月1日午夜以来经过的秒数吗？一天只有86400秒(一年31536000秒，2^32 = 4294967296——似乎已经足够，为什么不把时间分成两部分呢？)。顺便说一句，大约一年前，我尝试用闲置的旧树莓派在电视上搭建了一个小型计算站，但最新版本的Raspbian-i386系统表现相当糟糕。我记得几年前做类似项目时，系统响应速度更快。此外，几年前系统对外设的识别能力也更好。我想这似乎已成为一种趋势：如果你不购买新技术，你就完了，而你的旧设备很可能已经过时了。我认为我想要的词是“设计过时”。或许隧道尽头的一线希望是，我发现了RISC OS，尽管三键鼠标的问题破坏了气氛，然后我没时间继续了。我也在考虑将SARPi(Slackware)作为另一个候选方案，如果我能重新启动这个项目的话。也许还有Plan 9？现在的小孩似乎认为老电脑不够酷。也许这很公平，但它们对环境(和你的钱包)都有好处。

      回复

    6. 你能使用一个分析器，每次将 time_t 转换时都标记出来吗？为了保险起见，也可以加入对内存复制过小的警告。

      我猜一个棘手的问题可能是将 time_t 转换为实际上是 64 位的数据类型。例如，对于类似以下的代码：

        struct Callback {
    int64_t(*fn)(int64_t);
    int64_t context;
  }

      如果 time_t 被用作上下文，而 int64_t 随后被强制转换为 int32_t，这可能难以察觉。也许需要一些运行时类型信息来注释 int64_t 实际上是什么。

      回复

  13. 这会给支持 Debian 带来显著问题和额外工作吗？不是说我们不该咬紧牙关，只是好奇有多少库隐式依赖于 time 类型为 32 位。

    回复

    1. 现在可能比十年前或二十年前少一些额外工作。

      首先，OpenBSD(和其他系统？)早已这样做了。如果 Debian 这样做导致软件崩溃，那这些软件可能本来就存在问题。

      其次，大多数人现在使用 64 位操作系统和 64 位用户空间。这些系统一直使用 64 位 time_t(或至少使用了很长时间)，因此这里没有变化。此外，有人在之前的讨论中提到Trixie版本中i386架构没有变化……我没有跟踪Debian的计划，不知道他们何时会停止发布i386版本，但可能不会太远？

      回复

  14. 如果有人将32位时间序列化为32位整数，文件格式将不再匹配。如果有人有一长串受影响的程序列表，你就解决了2038问题。

    回复

  15. 32位系统难道没有64位类型吗？C语言有long long类型，据我所记得还有uint_least64_t之类的类型。为什么time_t必须限制在双字节范围内？

    回复

    1. > 32位系统难道没有64位类型吗？

      “long long”标准整数类型直到C99才被标准化，而此时Linux早已确立了其32位ABI。据我所知，“long long”最初由GCC提出，或者至少在C99之前多年GCC就已支持该类型。glibc也对该类型提供了一些支持。但可以肯定的是，time_t 在内核、glibc 及其他地方早已被固化为“long”(许多情况下字面意义上的固化——即在 (struct timeval).tv_sec 中使用 long 代替 time_t)。

      这个问题本可在数十年前解决，但过渡过程需要克服大量技术难题。我认为 OpenBSD 是第一个进行 32 位 ABI 转换的系统(约 2014 年)；他们打破了向后二进制兼容性，但迫使多个开源项目进行大量补丁修复以解决 time_t 的假设问题。glibc 和 musl-libc 完成转换所需的最后几块拼图直到几年后才到位(约 2020-2021 年)。对于glibc而言，该转换采用可选加入模式(如需保持二进制向后兼容性，可采用类似旧版64位off_t转换的方式)，而Debian直到现在才选择加入。

      回复

    2. 是的，32位系统支持64位类型。time_t作为u32类型是历史遗留。

      回复

  16. 对于无法重新编译的程序(因源代码不可用)，有哪些解决方案？例如旧游戏。

    回复

    1. 可能需要修改系统时间或伪造系统时间，以避免这些程序出现问题。

      回复

      1. 或者像 epoch 时间一样狂欢。

        =3

        回复

    2. 可能是使用 32 位时间戳的向后兼容运行时，该运行时在 2038 年后填充一个虚假时间(例如 1938 年)。例如 Steam 提供不同的运行时，Flatpak 也是如此。

      回复

  18. 为什么有人想用带符号整数存储时间？或者用任何带符号的数值类型？

    回复

    1. 这样人们就可以表示1970年之前发生的时间？你可以尝试将纪元调整为宇宙的估计年龄，但这样会遇到日历问题(预设格里高利历？)，在常见情况下会有巨大的常数(儒略日不好处理)，而且如果估计值被向上修订，仍然会遇到问题。

      回复

    2. 有符号区间是有用的，但大多数整数类型系统在从一个有符号整数减去另一个有符号整数时，会返回一个有符号数。

      你不得不做出选择：a) 对于小差异有合理的带符号行为，但无法表示大差异，b) 只能表示非负差异，但具有类型的完整宽度，c) 像 a，但还要说服你的编程系统进行混合带符号减法……就像 ptrdiff_t 一样。

      回复

    3. 你可以有一个纪元，现在你可以测量纪元之前的时间。就可表示的值的范围而言，这相当于将纪元置于更遥远的过去并使用无符号类型。因此，有符号/无符号类型实际上并不重要，除非某些语言在类型为有符号或无符号时工作得更好。例如，如果你试图计算两个时间之间的差值，也许最好让时间类型与结果类型匹配，即都使用有符号类型(尽管这并不能解决溢出问题)。

      回复

      1. 亵渎！世界于1970年1月1日UTC时间以当前状态诞生，你无法说服我否则。:P

        回复

    5. 我也曾对此感到好奇，我的最佳猜测是这样做可以让两个时间无需转换为有符号类型即可进行差值计算。尤其在64位系统中，额外的位并不会带来任何有用的功能。

      回复

    6. 这样计算“80年前”就不会得到一个未来的时间。

      回复

    7. 这样我的Arch Linux系统在实现时间旅行时还能正常工作。

      回复

    8. 这样你就可以写“delta = t1 – t0”。

      回复

  19. Kragen，进来评论一下。这是你展现才华的时刻。

    回复

  20. 令人失望，我原本希望在2035年左右能通过一份咨询工作轻松过渡到退休生活，现在却要应对这些主动性工作。

    我太年轻，没能从Y2K事件中受益

    回复

    1. 我没有。一位程序员同事相信世界末日论，开始全面备灾。为了储备地下掩体，他购买了价值数千美元的MREs。千禧年过去后毫无异样，他开始每天带MREs当午餐。我试吃后觉得不错。两年后我离开时，他仍在食用。

      回复

      1. 我今天才知道，有人因为Y2K事件患上了坏血病。看来它并不像想象中那么无害，对吧？

        回复

    2. 今天部署的许多嵌入式设备在15年后仍会存在，即使采取主动措施。而这些措施尚未实施，只是在未来几年内计划中。如果认真考虑，购买主流架构的开发套件可能是一项不错的投资。

      回复

      1. 可以确认，十多年前参与过嵌入式系统开发，这些系统至今仍在销售，并将在2038年继续在全球各地的工厂中运行。是的，这些系统确实存在(非安全关键型)Y2K38漏洞。项目负责人选择不投入资源修复这些漏洞，因为他届时已退休。

        回复

    3. 保持Yocto技能的更新 🙂

      所有那些被焊接到需要智能功能的设备上的32位ARM开发板都不会有Debian系统可用。

      话说，ESP32运行时默认如何存储时间？我对这些设备接触不多。

      回复

      1. IDF5+及以上版本支持64位，之前版本为32位

        回复

    4. 嗯，如果你想为退休后的事操心，那就想想所有那些嵌入了32位代码的医疗设备，它们肯定不会及时更新。

      回复

  21. 我真心认为到2038年不会有重大漏洞或服务中断。部分原因是我抱有天真的乐观主义，认为任何重要系统不仅会支持64位时间的操作系统/标准库，而且需要精确时间的重要系统很可能使用NTP/网络时间，这意味着其测试/开发/质量保证环境可以连接到模拟2038年后时间的测试网络时间服务器，以检查可能的崩溃。

    12年以上的时间来准备这件事。通常我对测试/开发系统、网络时间的正确配置等并不抱太大信心……但时间确实很长。即使我的所有假设都不成立，难道在十年内我们至少无法识别出32位时间的使用场景并制定应急计划？这似乎不太可能。

    不过，等Python开始支持纳秒级时间精度时再告诉我吧 :'(

    https://stackoverflow.com/a/10612166

    不过，我已经很久没有检查过他们是否支持了。至少在Windows系统中，所有系统级应用都使用64位/纳秒精度，至少在我处理过的案例中是这样。

    回复

    1. 当今的软件必须能够模拟未来的时间。抵押贷款长达30年。这已经是一个影响软件的问题。

      回复

    2. 我的担忧是，这个问题已经晚了12年。许多嵌入式设备在12年内不会被替换。我们现在有更多的小型设备运行各种系统，比25年前多得多。这些设备常位于难以触及的场所，制造商已停业，无法获得更新，且无人会在2038年对这些设备及其输出进行验证。

      目前投入生产的许多设备不支持64位时间，它们仍运行2015年认证或随机兼容的Linux版本。我希望你是对的，但无论如何，情况都会比Y2K更糟。

      回复

    3. 是12年，不是22年。

      今天购买的嵌入式设备可能在12年后仍在使用。

      回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：