到上海时间 2286 年 11 月 21 日 01:46:40，秒级的时间戳到 11 位，对各位写的代码有影响吗
zxcjqyy · b897846872 · 18 天前 · 11345 次点击秒：10000000000 毫秒：10000000000000 时区：Asia/Shanghai GMT：Sun Nov 21 2286 01:46:40 GMT+0800
对各位写的代码有影响吗？
 |
1
zxcjqyy OP 日期：5138/11/16
时间：17:46:40 时区：Asia/Shanghai GMT：Wed Nov 16 5138 17:46:40 GMT+0800 到 12 位了 |
 |
2
BigBai 18 天前  5
无所谓,那时候骨灰都不知道吹到哪里了
|
 |
3
kapaseker 18 天前 5
你想表达什么意思？
|
 |
4
mk3s 18 天前
现在我们项目不用 timestamp 了，因为范围太窄，1700 年怎么说（客户还真的需要）
|
|
5
zxcjqyy OP 日期：33658/09/27
时间：09:46:40 时区：Asia/Shanghai GMT：Fri Sep 27 33658 09:46:40 GMT+0800 到 13 位了 1000000000000 |
 |
6
c1985382 18 天前 via iPhone
260 年后？你的代码早化为乌有
|
 |
8
layxy 18 天前
到时候自有解决办法,重要的是你写的东西无论能不能运行到哪个时候都和你关系不大了
|
 |
9
festalstar5 18 天前
2038 年可能会对程序有点影响，看看项目还能不能坚持到。
|
 |
10
sagaxu 18 天前
1999 年新加坡拍了个电视剧，名为《力克千年虫》
|
 |
13
pweng286 18 天前 32
如果出 bug 了.请把我复活.
|
 |
14
yulgang 18 天前
真是操不完的心啊
 |
 |
15
RJH 18 天前
建议搜一下千年虫这个关键词，当时也是类似问题
|
 |
17
CodeCodeStudy 18 天前
那就使用 bigint, long
|
 |
18
vicalloy 18 天前
说个比较近的 对于 32 位系统的 unix 时间戳在 2038 就会溢出。
基本上 32 位的 Linux 系统都会有问题。 注：别以为现在没有 32 位系统了，不少嵌入式设备都是 32 位的，比如路由器。 |
 |
19
jjianwen68 18 天前
给他们个机会，不然到时候怎么想起复活你呢
|
 |
20
fengye0509 18 天前
200 多年以后了，说不定地球都爆炸了
|
 |
21
daybreakfangyang 18 天前 3
杞人忧天：比喻不必要的或缺乏根据的忧虑。
（出自《列子·天瑞》中“杞国有人忧天地崩坠”的故事） |
 |
22
huangsijun17 18 天前
@vicalloy #18 64 位系统很多软件、库也是 32 位的，兼容性未知。
|
 |
23
justfindu 18 天前
我们现在用 datetime , 到哪都无所谓
|
 |
25
listen2wind 18 天前
到时候把 bug 烧给我，我托梦给你改
|
 |
26
iApp 18 天前
凡是重要的系统都是有人维护的,出问题就有人去解决,那些出问题又没人发现的都是不重要的,出问题到时候挂了就挂了,自然会被淘汰掉,有新的顶上去,这也是一种自然选择
|
 |
27
iamqk 18 天前
260 多年后现有的程序语言（不夸张的说，有的国家的官方语言也是如此）
以及 SDK/api 等早就更新换代了 这个问题在设计的时候应该就被解决了 不用担心 |
 |
28
franklinray 18 天前
如果出了 BUG ，那就来底下扣我的奖金吧
|
 |
29
sentinelK 18 天前 2
200 多年前的“系统”到现在兼容性有多少？
过度的设计，同时也就意味着过度的浪费。 工程学不讲究最强，讲究最优性价比。 |
 |
30
fkdtz 18 天前
50 亿年后地球被太阳吞没，对各位写的代码有影响吗
 |
 |
31
linuxsir2020 18 天前
重生之我在 202x 年写 bug :)。。。。。代码能存活到那时候再说吧
|
 |
32
c2ch 18 天前
Integer.Max_Value 是 java.lang 包的 Java Integer 类中的一个数字。 它是可以用 32 位表示的最大可能整数。 它的精确值为 2147483647 。这个秒级时间戳转成时间是：2038-01-19 11:14:07 Asia/Shanghai
|
 |
33
pkoukk 18 天前
你难道觉得自己的系统能运行到 200 年后？
|
 |
34
gbw1992 18 天前
以各位的代码水平, 目测没有能运行到 2286 年的可能性
 |
 |
35
thinkwei2012 18 天前
下一代程序员要解决的事情，笑
|
 |
36
lloovve 18 天前 via iPhone
省流，闲的。
|
 |
37
elevioux 18 天前
200 年。计算机可能都进化几代了。人早死了。公司早没了。你的代码早都运行不了了。
|
 |
38
Goooooos 18 天前
先把 mysql timestamp 2038 的事情解决吧
|
 |
39
1018ji 18 天前
鞭尸还能咋整
|
 |
40
vialon17 18 天前
哈哈，到时候发现妳代码不行了，
就做个克隆或者解冻 再把 OP 拉起来问问代码咋回事跑不动了。 完事再扔回去继续冰冻， |
 |
41
belin520 18 天前
我以为是 2086 年，觉得还能讨论一下
|
 |
43
shenqi 18 天前
不错，很好的问题，希望我的代码能在那时候还在运行。
|
 |
44
null113 18 天前
杞人忧天
|
 |
45
hahastudio 18 天前
按每几年基础架构就会有翻新的进程来看，这么多年之后架构上肯定解决这个问题了
这个真可以相信后人的智慧，倒不如说现在想的方案后面可能都不好用 |
 |
46
dhb233 18 天前
秒级时间戳 11 位是啥意思？小数点之后 11 位？那岂不是飞秒级别了？
|
 |
47
lxqxqxq 18 天前
2086 年 都不关我事
 |
 |
48
yph007595 18 天前
11 位？我 10 位都不 care
|
 |
49
NewYear 18 天前
我还以为你说这几天会加长度，我想说 10 位和 11 位肉眼根本看不出来。
结果你给我说是几百年后的事情，有没有必要这么扯淡，两百年前还是封建时代，这有什么可比性。 现在大量的设计本质上是重复了 20 世纪的“千年虫问题”，即便是我这样的“资深人士”（在外面身份都是自己给的）为了方便其实也用了存在千年虫问题的设计，但是这有什么问题呢？如果说上个世纪末 IT 发展迅速，而且也是起步摸索阶段导致了千年虫问题，我们这一代何尝不是在错误的基础上继续犯错？但是那又如何，现在离 2100 年都还有七十多年，总不能我设计的那些玩意还能运行这么久吧，就算是……那我也死成“渣渣辉”了，还管他洪水滔天？ 不客气的说，我的想法还是比较单纯的，但很难说会不会有人设计一个“死后早就洪水滔天的机制”，比如说设计一些后门，在死后触发所有核弹的启动并轰炸主要发达城市，进而让各核平有爱的国家同时启动核反击（核反击的机制是不去辨别到底谁是善意谁是恶意，也根本不能很确定对方到底目标是轰炸哪个国家，能考虑的时间很短，通常都设定为不做过多讨论，快速决策，目标是打击主要对手的全部主要城市。[核心思想是：有人在捅我腰子，那我拉着你们一起玩玩]）。 |
 |
50
DAFEIGEGE 18 天前
别操心，后人比你更聪明
|
 |
51
webs 18 天前
那时回头看，两百多年的程序顶多就是个 hello world 级别的
|
 |
52
mon6912640 18 天前
换个角度，260 年前，中国处于大清康乾盛世时期，英国的工业革命刚刚开始
|
 |
53
janus77 18 天前
整个计算机行业满打满算都没 200 年吧
|
 |
54
tinydancer 18 天前
相信后人的智慧
|
 |
55
mwuxlcanrh 18 天前
你想多了，你写的代码 10 年后就没有人调用了
|
 |
56
Rickkkkkkk 18 天前
2038 才是新的千年虫
|
 |
57
RIckV2 18 天前
我相信我们公司活不到那时候
|
 |
58
fun201108 18 天前
用解决 2038 年问题的方法解决即可
|
 |
59
Tink 18 天前
用字符串
|
 |
60
cenbiq 18 天前
Man, what do you say?
|
 |
61
GDAOE 18 天前
到时一句 prompt 解决
|
 |
62
xqk111 18 天前
活不到那一天了
|
 |
63
ererrrr 18 天前
我总感觉 NewYear 这个人
持续性的用 ai 回答问题 非常的多 |
 |
64
bowling 18 天前
孙子都没了，200 年后代码估计都不存在了
|
 |
65
JingKeWu 18 天前
都不关我事
|
 |
66
lyyhello 18 天前
相信后来人的智慧
|
 |
67
seansong 18 天前
没有啥影响，毕竟代码里面并没有靠数位数去判断什么东西
|
 |
68
littlewing 18 天前
没动你想表达什么 11 位 2^11 这完全不够啊
|
 |
69
Hilalum 18 天前
|
 |
70
cnkuner 18 天前
两百年后还用代码吗？
|
 |
71
prosgtsr 18 天前
相信后人的智慧
|
 |
72
llsquaer 18 天前
要不用 bigint 存，2000.1.1 0:0:0 存 自己算。
|
 |
73
Abbeyok 18 天前 via iPhone
又有人在这抖机灵了，昨天是时光机，今天是考虑 200 年后今天的代码能不能运行
|
 |
74
caicaiwoshishui 18 天前
并影响 那个是时候估计又是 石器时代
|
 |
75
Pipecraft 18 天前
是一个好问题。
这个历史包袱还是交给 200 年后的 AI 解决吧。 现在大可不必提前优化代码，大家思考下一个问题吧。 |
 |
76
i386 18 天前 via iPhone
不利于团结的话不要说😄😂
|
 |
77
Rorysky 18 天前
是不是工作不饱和，想那么多，手头任务都做完了么
|
 |
78
musi 18 天前
你是不是还会担心你死后钱没花完怎么办，建议你现在先把你的钱都转给我
|
 |
79
snoopygao 18 天前
千年虫，80 后在懵懂和信息技术大爆发时代路过
|
|
80
Pipecraft 18 天前
@Pipecraft #75 检查了一下正在写的程序，还真兼容到 2086 年。我需要重构吗？好纠结啊 ...
https://github.com/utags/utags-bookmarks/blob/main/src/utils/date.ts  |
 |
81
Felldeadbird 18 天前
你不如先担心 2038 年，int 长度不够，不少程序出错的情况。 你去考虑骨灰都被扬的未来？
|
 |
82
catazshadow 18 天前
奉劝各位还是早日重构了,到时候 50 岁出列把月亮炸了,结果 DNS 系统里的时间戳出 bug 地球飞不走不完蛋了(手动狗头
|
 |
83
laydown 18 天前
那时候不一定有人类；如果人类还存在，那么不一定还用这套系统；如果这套系统还在用，那时候，或许解决这个问题，不需要话费 1 秒钟。我觉得回答这个问题就是在浪费了时间，浪费自己和大家的时间。
|
 |
84
moefishtang 18 天前 via Android
@vialon17 什么油纸包着的德国工程师
|
 |
85
Yanlongli 18 天前
先得活到那个时候，2038 问题都一大堆
|
 |
86
wuxilaoshiren 18 天前
看了半天硬是没看懂你在说啥
|
 |
87
lefer 18 天前
按照现在国际的紧张局势，我都不知道 100 年后人类还在不在 ...
|
 |
88
refear99 18 天前
谁还在用 int bigint 和 timestamp 啊
timestamp 跟数据库时区走的，容易误操作 int 不够长 bigint 虽然能用负数表示 1970 之前，但是有些系统不支持负的秒级时间戳 datetime 才是最优解 |
 |
89
zjsxwc 18 天前
毫无影响，
10 位的时间戳肯定是用 字符串或者 bigint 来存， 变长字符串不提， bigint 里单单有符号 bigint 最大也是 9,223,372,036,854,775,807 这个 19 位长度，19 位完全可以容纳 op 说的 11 位长度。 |
 |
90
leegradyllljjjj 18 天前
跟我当年操心序列号 2099 到期了，软件不能使用了一样。公司都百分百倒闭的，哪有那么多百年老店
|
 |
91
Kazetachinu 18 天前
一说千年虫，我记得还是看 DVD 张帝说的
 |
 |
92
rootsir 18 天前
和你没啥关系
|
 |
93
tyrone2333 18 天前
99.999% 的公司活不到那时候
|
 |
94
rick13 18 天前
400 年后三体人打过来了，对我也没影响
|
 |
95
soulflysimple123 18 天前
时间用 datetime 啊
|
 |
96
realpg 18 天前
不是 java 人 不是 js 人 所以时间戳对我来说就是秒 int64 足够用
|
 |
97
LieEar 18 天前
我写的代码，我上班的公司能活过 5 年就算小概率事件了。谁还关心这个
|
 |
98
cocomanber 18 天前
写业务得考虑这么多场景吗，难道每天笑嘻嘻到点下班只有我？
|
 |
99
zmqking 18 天前
兄弟，你有做伟人的特质，真的，程序应该也要考虑百年大计 [手动狗头]
|
 |
100
zerovoid 18 天前 1
200 年后，人类如果还在用电子计算机，人类如果还呆在地球上敲代码，那人类这辈子也差不多了。
|
Select Language