Fule

我觉得这个逻辑有点问题：既然有赛博洁癖，理论上就不会在电脑里乱装软件，只会安装那些质量够高、必须安装的软件，这样电脑也不会乱，进而不会有重装系统的必要。就像喜欢整洁的房间应该一开始就不会乱丢东西，丢了一大堆了就看着不顺眼想换个房间。所以解决的办法就是别在电脑里乱装软件，另外备个虚拟机可以随便装，也方便还原什么的。

不需要和其他程序员交流并且其他程序员也不会找你的程序员。

让我想起很久之前看过的一个英语视频，说是现在不管什么事儿动不动就 Awesome ，即过度夸张了含义又忽略了很多其它更合适的词汇。确实现在就是这么个浮夸的时代。

也可能是电源质量问题，虽然瓦数够，但纯电源个体质量问题？

能户外尽量户外。如果说游戏，建议《我的世界》

小时候父母支持我买了人生第一台电脑，后来和来自中部省份的同事说起当时那台电脑的配置和价格，同事说就那些钱，当时够在他们那里买套房了。——没想到父母对我的支持这么大！
小时候看到路上一辆别克小车觉得特别漂亮，而家里也有十几辆 MatchBox 的模型小车，特别喜欢车，现在也已经换到第 5 辆车了，确实已经没有那买十几辆车的财力了。。。

当然，如果需求变更，下单时间查询原来只是某天到某天，现在改为某天某时到某天某日，上述做法导致前后端都需要修改，所以如果想避免/预判需求更改导致的代码更改，那么前端依然按照需求要求带时分秒或不带时分秒，而后端则根据传入的参数是否带有时分秒数据而分别进行查询。

我觉得这个问题不能一刀切，需要根据是否需要“时间”这个概念来确定如何保存和查询。

对于数据存储来说，例如，对于“下单时间”这个概念，显然时分秒是必要的，而对于生日这个概念，（通常）时分秒是没有意义的，所以前者需要存储时分秒数据，后者只需要存储年月日数据而时分秒都是 0 或者存储系统支持纯年月日类型的话更好。

对于查询，如果是上述下单日期，同样基于业务要求来决定是否需要传入和处理时分秒数据。比如业务有需求要查询某日几点几分到几点几分的数据，则接口参数需要包含时分秒而查询就是基于大于等于并且小于等于的范围。而如果只是需求查询几号到几号的数据，则接口参数不需要包含时分秒或者时分秒为 0 而执行时基于大于等于 BeginDate 并且小于 QueryEndDate + 1 day 的范围。如果是上述生日数据，因为本身存储不带时分秒，所以接口参数也不带时分秒或时分秒为 0 而查询基于大于等于并且小于等于的逻辑。

一来人各有志，二来宏观来看每个方向都有试图努力理解和推进的人才会扩大人类进步的可能性，无论这种进步是哪个方向的。