codehz

听起来是 HDR 或者色彩空间的问题（
一般来说截图全部会统一到 sRGB ，然后如果中间处理出错，就会颜色映射到错误的颜色去

@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

可以直接这样启动 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 用不了了）