多种处理器架构。
按照操作系统的分类，属于分时操作系统。
该系统最早由肯·汤普逊、丹尼斯·里奇和道格拉斯·麦克罗伊于1969年在AT＆T的贝尔实验室开发。
Unix系统有很多衍生产物。
iOS 基于的 Darwin 正是 Unix 的分支之一。
iOS作为一个系统一定程度上继承了Unix的特性。
既然是系统，那么不可避免会涉及到计时的问题。
与人类一般使用“年+月+日”的计数格式不同。
Unix 采用了一种完全不同的计时方式：
在Unix系统中计时方式是先将（UTC时区） 1970 年 1 月 1 日 00:00 设定为 0 点。
举个栗子。
2014年6月22日18时30分25秒。
表示出来的话为1403433025 秒。
换算成对应的二进制在Unix系统下表示时间。
这种计时方法被称为时间戳。
iOS系统也沿袭了Unix这一计时方法。
也正因此，iOS 中时间的设定最多也只能回溯到 UTC时区1970 年 1 月 1 日 00:00 也是这个原因。
仅仅是设置成这个时间的话不会有什么问题。
但涉及到一些特殊的在局部关键功能具有查询过往信息的规则的时候
将时间设置成UTC时区1970 年 1 月 1 日 00:00很容易出问题。
尽管多数时候可以通过人为的因素避免触发这个漏洞。
但蘋果手机开机的时候就有一个这样强制查询过往信息的机制这个几乎无法避免。
这个机制没办法取消，因为关机重启之后手机肯定是要读取一部分先前的日志数据的。
这种情况下如果时间戳是正常时间的话，那么读取先前的日志数据并不会有什么问题。
但当UTC时区1970 年 1 月 1 日 00:00的时候，这个时候时间戳的时间是0。
当局部时间比时间戳 0 点更早的情况下。
应该怎么表示比时间戳 0 点更早的时间？
似乎没什么好办法。
尽管没别的好办法，系统是机器。
又不是拥有智慧的生物，它一样是要通过查询机制找到更早时间的。
这个时候就会在时间戳0的基础上进行-1操作。
（这是为了在系统时间戳表达的时间上减去相差的秒数来查询之前的内容）
不过在0的基础上-1就比较悲催了。
得到的结果并不是-1。
0-1≠-1？
听起来很匪夷所思，但实际上在程序里面涉及到这种现象比比皆是。
因为 Unix 采用了二进制的方式来存储。
二进制数据在执行在执行00……0-1
实际进行的的运算是：（1）00……0-1（ps：省略号中有61个0）
得到的结果是11……1（ps：省略号中有61个1）
这样的话0-1≠-1
得到的数实际是2的64方-1。
类似于这种的例子在计算机的世界里有很多。
比如说两个正数相加结果为0这种情况。
林灰记得以前玩ACM的时候经常遇到那种比较蛋疼的编程题。
表面上要求两个数相加。
听起来要求很简单。
但跑程序测试的时候遇到的测试数据都是那种超大数。
但实际操作的时候必须要考虑数据溢出的情况。
总而言之，计算机世界。
一个奇妙的世界。
在Unix里当时间戳为0的时候进行求差也会遇到