@mytharcher 如果业务逻辑的关注点是年、月、日这些“人为编制的序号”，那么更好的做法是抽出年、月、日建索引，检索时在索引字段上按照更符合人类认知的闭区间来筛选，而不是在 timestamp 上划分范围。

@brader 也就是说，其实 Calendar 相关的东西是跟 time 不同逻辑的数据类型，它不是物理意义上的时间长度和时刻坐标，而是人为的、人文的编号。如果要处理日历上的日期，复杂度远比“存储用 UTC timestamp ，给人看的交给前端去做转换”复杂得多。以前在一个教务系统招生模块里就是因为大意用普通的时间类型保存生日而碰到了中国实行夏时制的年份里出生在夏时制边缘日子里的学生因为算出来的“年龄”不对而无法报名的问题。

作为用户我只想用原生 app……但是想到我很少为优秀的原生 app 付钱，那么，作为雪花，我不是无辜的

另外，除了小数部分之外，23:59:59 还有个问题是表示不了闰秒。

当然，实际应用中，如果业务不是全天候的，或者在那特定一两秒的业务量本来就少，也能承受少量错误的代价，就无所谓了。

如果做比较的时候能保证传入的时间先 truncate 到确定的精度，可以用两端都闭合。否则只能左闭右开才能保证正确性。

因为早在很多年前厂家们就没动力卷桌面 GUI 赛道了，更不要说 native GUI

顺便说一下，enumerate 和 zip 不是语法糖，也跟你“没有学习面向对象的知识”无关。可以算是函数式编程（跟面向对象编程平等的另一种范式）里比较基础的用法。

如果你有这么大的数据量，但给你带来的收益让你连一年不到 5 万的都觉得存储+下载费用都觉得太高，那是不是要考虑一下这个业务的价值，换个赛道了？

那么为啥国内都要做保活呢，为啥混战了这么多年才有好几路的统一推送呢？

发行版自带打包好的内核，开启发行版更新

虽然不懂，但是……有人嫌别人 996 不够卷，想把人当机器。有人要给机器人下班。这个世界啊。

国内服务器的价格，带宽费是大头，你让它如何廉价

趁着 5.7 EoL 的机会，渲染一下恐怖气氛，做一次业务系统大改版……

非容器化的传统部署，至少要写好 systemd unit ，配好日志定时切分轮替。初始部署以及做过基础设施配置变更后至少要 reboot 一次服务器看能否自动启动完毕且运行正常。

这不是给苹果打工。从打工的角度，苹果可不一定看得上你。

用不用软路由取决于你有没有普通家宽用户没听说过的各种小众需求，而不是哪一年。

怪选型的人

MBP 2017 ，退回到了 High Sierra……最大的问题是各种应用也要去找老版本的😭