####### 问题描述: 项目中有一个请假的功能,其业务逻辑很简单:

• 很贴切接近现实世界,根据请假类型(事假,病假,法定,调休...等)的不同,可以请到的假天数也不一样
• 通过选择请假开始时间和结束时间划一个时间段,然后这个时间段就是假期的黄金时间,多一秒少一秒意味着会影响档期的安排

开始错误的做法❌:

比如: 我想请一个三天的假,开始时间: 6月1号, 结束时间: 6月3号.
按照现实生活来看,这完全没毛病嘛,  请假以天为单位,
后台接收参数是一个时间戳, 于是时间控件选择出来
的时间戳都是每天早上 0点0分0秒的时间,
这样一算三天假就变成2天了,假期严重缩水.... 

正确的姿势✅

经过产品经理和后台的磋商,意淫出了一个比较奇葩的方案,开始时间
加1s , 结束时间减1s,这样子,说这样才不会踩到边界,从而影响破坏档
期的平衡....  可问题还是差一点就是三天变两天的那个坑还没能跳出来
|---|---|---| 比如这个线段,分成3份却有4个顶点一样,就跟请3天的假
有4个时间节点一样...

/// MARK: - 根据产品他们的想法进行了延伸,把需求做到位
#结束时间 + 86400 -1  ==> 相当于当天最后一秒就跨越到第二天去了
#开始时间还是原样+1 ==> 每天从01s开始 到 23:59:59.... 瞬间感觉
一天中被活生生掐掉了2s的,因为不影响大局(一天为单位的),不如不
踩边界,各退一步.如此就完美了

总结: 比如有两个人平时关系很好,但是有一天为了一些幺蛾子的小事情在争吵,并且互不退让,争吵的水火交融,不可开交,公说公有理婆说婆有理,旁观者看了也说不清... 此时此刻若是这俩人内心多一点宽容,各退让一步, 何至于争吵不休? 扯得有点远,感觉也就是那么回事, 有时候吃点亏也没什么,能够影响大局的往往就是一些细枝末节的小分寸... @(成大事者,不拘小节) VS @(失之毫厘,谬以千里)