@px920906 时间戳的基本是关于闰秒的问题 https://alexwlchan.net/2019/05/falsehoods-programmers-believe-about-unix-time/
然后 24 点是因为某些地区 dst 在 0 点调整
年份的问题，0 不是一个有效的年份，公元一年的前一年是公元前一年
年份不同格式不同则是因为有种格式是周日历，而这个格式下为了确保同一周是属于同一年，就会对年份数字进行调整，我记得某 java 格式化就会遇到这个问题
月的长度: 1752 年 9 月历法变更
星期的问题也源于此
时区差异:印度在殖民地时期，三个时区分别为 GMT+4:51 GMT+5:21 和 GMT+5:54 (显然是人为故意设置的） https://en.wikipedia.org/wiki/UTC%2B04:51
时区差异变化是因为不同国家的 DST 不同
下一个星期的同一时间这个问题，除了历法变更这种不会再有（希望如此）的事情之外，主要还是闰秒，DST 的影响）

文档上都这样写了，确实是约等于 root
https://gist.github.com/PwnPeter/3f0a678bf44902eae07486c9cc589c25
可以直接这样启动 payload

正经回答一下好了，存时间就别限制位数了，数据库也不差这么点，32 位时间戳很快就会撞到 2038 了（虽然数据库用十进制的倒是问题不大，但是这种莫名其妙的 11 的限制不会有啥好处）
不过其实如果不是性能非常要紧的话，存 iso8601 就足够用了（数据库自带时间类型，可以自动转换的就忽略这点），主要除了程序处理，有时候还需要人工检查问题的，看时间戳不如看可读性好的文本

关于 unix 时间戳的几个错误认知：
1. unix 时间戳表示从 UTC 1970 年 1 月 1 日 0 时 0 分到现在的秒数，错❌
2. 等待一秒后 unix 时间戳+1 ，错❌
3. 那么最起码，unix 时间戳不会递减，错❌
关于时间格式的几个错误认知：
1. 24:12:34 是一个非法的时间，错❌
2. 每一个整数都是一个可能的年份，错❌
3. 同一时间的年份在任何时间格式下都是一样的数字（如果有），错❌
4. 每月的日数在 28 到 31 之间，错❌
5. 星期六之前一定是星期五，错❌
6. 时区之间的差异最短是 15 分钟，错❌
7. 时区一定是到 UTC 到固定时间差异，错❌
8. 下一个星期的同一时间一定是当前时间+7*864000 秒，错❌
9. 你可以设计一个更好的时间系统，错❌

还记得之前的 jndi 漏洞吗（
听着就是在造 RCE(

可以是可以，就是容易破坏其他程序的功能）——你直接改 /etc/passwd 就好了
有些程序功能会通过默认 shell 来执行命令，这时候改成不兼容的其他程序就可能会炸了

只是 uwp 可以改，没说 win32 可以改
很多 win32 程序根本写死路径，改了怎么兼容）

wsl 也要商店安装的版本，于是 win10 用不了了）

本地加密为啥会提供 api 支持呢？
api 都是在服务端处理的，怎么能在服务端做客户端加密呢

ip 地址是<span id="x">1.1.1.1</span><button onclick="navigator.clipboard.writeText(x.innerText)">复制</button>

@litguy 不用锁，读 random 和使用 getrandom 系统调用是一样的结果，都是独立生成的

(linux 的话，可以要求 gcc 生成文件到 /dev/stdout 的，然后你直接 pipe 一下就可以接收了

(再动态一点可以考虑包一层组件，虽然 hook 不能写条件，但是组件可以随便加
做类似无限滚动的话还可以用 useSWRInfinite

@RRRSSS useSWR key 为 null 的时候不会发出请求，完美符合需求

@RRRSSS 这就是为啥不应该用 useEffect 来做这种操作（
https://blog.skk.moe/post/why-you-should-not-fetch-data-directly-in-use-effect/

react query 不是自带缓存管理的吗（
重复写又不会重复请求

顺带提个需求，切换的时候同步切换"自动在全屏幕中隐藏和显示菜单栏"
之所以有这个需求，是因为某些软件全屏会检测菜单栏，有菜单栏就会启动缩放模式（
但是显示 notch 的时候菜单栏一起显示其实问题不大）

Telegram: Send without sound

能不能提供一个捷径 /或者 apple script 一类的可以外部操作的 api ，以方便在不启动界面的情况下快速操作切换（