“有的语言会把时间戳定义为当前时区自 1970-1-1T00:00:00 到现在的毫秒数”
根本就没有语言这么做，再者说就算这么做了，也跟我时间戳（无论是毫秒还是秒）这个普遍概念没关系了。

@nothingistrue
[1-中国标准时间.jpg]( https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/1-%E4%B8%AD%E5%9B%BD%E6%A0%87%E5%87%86%E6%97%B6%E9%97%B4.jpg)

[2-亚马逊标准时间.jpg]( https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/2-%E4%BA%9A%E9%A9%AC%E9%80%8A%E6%A0%87%E5%87%86%E6%97%B6%E9%97%B4.jpg)

你看看在切换时间后，时间戳这两个数字差了多少？ 36438 毫秒，也就是 36.4 秒，就是我在第一个运行完、截图、改时区等操作花了一会儿而已。

@nothingistrue
ISO 是国际标准化组织，又不是只面向计算机从业者的，8601 是规定了显示方法。数据的存储和显示相分离的设计原则不是再正常不过了吗？
我一开始不就说了使用“毫秒”级时间戳。确实时间戳没有国际标准。各种语言都可以轻松地处理。
Python 的 time.time()，Java 的 System.currentTimeMills()，JavaScript 的 Date.now()，也就差一个 1000 处理。推荐使用“毫秒”时间戳只是因为整数比浮点更好处理罢了。
最重要是，处理过程中没有涉及到任何“时区”相关的东西？

这个数字只跟时间点有关。如果你没条件找个其它时区的人跟你一起试的话。至少换个系统时区再试试，关键是



你到底有没有试过？

@nothingistrue 扯远了。
回到用 long 存时间戳的问题上，假如现在有一台 MySQL （无论在哪儿），Java 程序 1 在北京，Java 程序 2 在纽约，它们都连接着这个数据库。

实验 1：
先是北京产生了一条记录，然后 10 分钟后纽约产生了一条记录。Java 程序都使用 System.currentTimeMillis()将得到的 long 数字存入数据库。那么这两条记录差的大概就是 10*60*1000 毫秒。无论你是否设置了 serverTimezone 参数，可测试。

实验 2：
使用如下 Java 程序插入一条新纪录。
String url = "jdbc:mysql://localhost:3306/test?serverTimezone=UTC%2B8";
Connection conn = DriverManager.getConnection(url, "root", "password");
PreparedStatement stmt = conn.prepareStatement("INSERT INTO record(`time`) VALUES(?)");
Date date = new Date();
stmt.setObject(1, date);
stmt.execute();
stmt.close();
conn.close();
在保留和去除 serverTimezone=UTC%2B8 这个参数的情况下分别插入一条数据。那么你在数据库里看到的时间差别就很大。这是因为虽然 MySQL 底层虽然用了存整形的方法存时间戳。但你 insert 的时候仍然得用字符串：
INSERT INTO record(`time`) VALUES('2022-07-13 00:00:00')
这就有了借助时区的转换过程，然后就会有问题。

@nothingistrue MySQL 的 Timestamp 会在你 select 帮你格式化成文本帮助你阅读，格式化时就会用到时区信息，但底层的数字是没有的时区信息的。

对应的，你套上 UNIX_TIMESTAMP()函数，然后再看看。
SELECT
UNIX_TIMESTAMP(CURRENT_TIMESTAMP()),UNIX_TIMESTAMP(LOCALTIMESTAMP()),UNIX_TIMESTAMP(UTC_TIMESTAMP()),UNIX_TIMESTAMP(NOW())
FROM DUAL;

世界上各个时区的人在同一时间点调用 System.currentTimeMillis() 拿到的是同一个数字。
那用这个数字来表示时间点就不会因为时区、显示而产生歧义了啊

@nothingistrue 不带时区的。你可以先正常运行一遍：
System.out.println(System.currentTimeMillis());
然后，换个时区再运行一次，你看看这两个数字差了多少就知道了。（毫秒）

时间戳只是针对某个时间点的偏移量。只不过这个时间点是 UTC 1970 年 1 月 1 日 0 时 0 分 0 秒
完全可以说时间戳是从 UTC+8 1970 年 1 月 1 日 8 时 0 分 0 秒 起至现在的秒数，这俩就是同一个时间点。
只不过挑一个基准时间点，总归要挑个规整点的罢了。

漏了这个
https://www.liaoxuefeng.com/wiki/1252599548343744/1255943660631584

@nothingistrue
@MuXia
时间戳是跟当前在什么时区无关的。
https://www.liaoxuefeng.com/article/978494994163392

/t/861083
作为一个 Flutter 吹，现在还是推荐 React （和 ts 结合更好）。
Flutter 现在生态确实还不好。

用 long 存毫秒级时间戳，足够用到天荒地老。
MySQL 的 timestamp 不要用，只有 4 字节，除非你想在 2038 年引起下一个千年虫。

对于精准时间点，时间戳特别好用。没有时区、夏令时问题。闰秒操作系统会帮你吃掉。
连接数据库不用担心 serverTimezone=GMT%2B8 问题
时间不对，排查点就基本可以缩小到 Format

Figma 真的是标杆。说明了这个技术确实有应用场景，而且非常实用。
B 站在视频上传时就能选择封面，似乎就用到了 wasm 技术。

我挺喜欢这个技术，也看好它的未来。但一般人确实没有用它的必要。
①普通增删改查用不上 ②技术要求比较高，普通开发者玩不转
感觉处境类似于 WebGL 。

@lujiaosama 像 R 星，卡表这种确实没有太亲 PS ，但也没有亲 XBOX 。他们应该算是亲主机。
亲主机的话是 PS/XBOX ，亲微软的话是 XBOX/PC 。看起来是交集，但实际意味着在哪边 xbox 都没有不可替代性。
你看好 xbox 的想法我非常理解，但“索尼断气”的声响从 x1x 打 ps4pro 的时候就有了，现在我仍然觉得 ps 更好。
我也看好 xbox 的未来，但未来什么时候来就是个问题。
本来打算继续全平台的，但 PC 有矿潮，而 XSX 目前确实还没有购买理由
（非 xbox 黑，反正哪个平台我都能玩到，不推荐的理由是因为上时代 x1x 真的吃灰了）

@lujiaosama XBOX 和 PC 不是一体的！！！地平线、战神上了 PC 但没上 XBOX 。《死亡搁浅》只上了 PC 。

如果现在要全平台的话，我会推荐的顺序是 PS5 、PC 和 Switch 不分主次、最后才是 xsx 。如果有人要买 xbox ，我会直接推荐加钱上 PC 。

1 、索尼的游戏现在不是独占也是限时独占，这意味着你要玩，至少得落后 ps 两三年，战神 4 就隔了 3 年多。
2 、抛开老黄历。PS5 新出的独占游戏有《恶魂重置版》、《瑞奇与叮当时空跳转》、《死亡回归》，xsx 呢？《 Scorn 》、《灵媒》。对比下。
3 、就算是老游戏，很多游戏也非常值得玩，比如《旺达与巨像》。游戏适配也要花不少功夫，而官方都没公布，连个盼头都没有。
4 、就算不是独占。PS 也是明显的亲妈，你看看 FF7 重置版。再者国内的讨论度、资料、视频基本都集中在 PS 这边。
5 、《星空》 PS 独不占也是应该加钱买 PC 而不是 XBOX 啊，FPS 用手柄就是一个蛋疼。

xbox 上玩过的游戏：大表哥 2 、量子破碎、瘟 yi 传说、丧 shi 围城、星战绝地、毛线小精灵 1+2 、光环。
亲微软的有名厂商就是 EA 和 贝塞斯达。但这俩有很多 FPS 游戏，你懂得。
大表哥 2 和星战在 x1x 上性能更好，其它方面则没有区别。

现有 switch 、ps4pro 、x1x 、ps5 和 1070 台式机的全平台玩家告诉你
选 PS5 。
个人对价格并不是很在意，追求的是在哪个平台的体验更好。最重要的是看厂家的态度。大部分游戏厂商都是亲 ps 的，尤其是日厂。
现在女神异闻录 5 、神海、旺达与巨像、神秘海域、声名狼藉次子、吃人的大舅、血缘仍然是 ps4 上的独占游戏。
合金装备 5 是索尼做的汉化。蝙蝠侠阿卡姆是 ps 平台画质更好。
漫威银河护卫队、如龙会利用 ps 手柄上的扬声器功能，说明人家更愿意适配 ps 。
控制在 ps5 上有用上自适应扳机功能，体验非常好。
其它的尼尔、仁王、怪物猎人世界、最终幻想、COD 等游戏都有明显的亲 ps 倾向。

1 、Lambda 是肯定要用的，要不然多麻烦
2 、时间的我也喜欢用时间戳计算然后转成 Instant （时间段长度固定，与时区无关的情况下）。其它几个用的比较少，数据库里存的和返回给前端的都是毫秒时间戳，交给前端去格式化。但 Date 、Calendar 肯定不用。
3 、try-with-resources 会用，但用的不多。因为如果你调用的方法会抛出检查型异常的话，那么放在开头的括号里的很麻烦。（我倾向于方法生命无 throws ）
4 、stream api 用的挺多的，但 for 也在用。
因为 stream 中间有个函数会抛出检查型异常的话，处理也比较麻烦，不优雅。或者只是 steam api 用得太多了。

只考虑 LTS 版 Java ，现在开新项目已经可以直接上 Java 11 了。
那乐观估计，2025 年至少得开始学 Java 17 了。

顺便问一下，学新版本是只看新的部分还是直接重学当复习比较好呢？

这种结构不属于 Java 的“包袱”而是财富，Java 根本没有规定要这么处理。
搞成这样的本质原因是大部分人根本不知道怎么设计一个项目的代码结构，目前的结构是优胜劣汰下来的、有成功经历、受到广泛认可的，统一的设计也促进了 Java 生态圈的发展。

但这种结构确实不适合直接拿到别的语言里，只能拿来参考。之前接触 nodejs 、python 后端的时候，按 Java 的方式写会怪怪的，不按它的写又不知道怎么组织，很头疼。

All in two ，NAS 就负责存储。
/t/860324