1. Unix时间戳
UNIX时间戳：Unix时间戳（英文为Unix epoch, Unix time, POSIX time 或 Unix timestamp）
是从1970年1月1日（UTC/GMT的午夜）开始所经过的秒数，不考虑闰秒。
UNIX时间戳的0按照ISO 8601规范为 ：1970-01-01T00:00:00Z.
一个小时表示为UNIX时间戳格式为：3600秒；一天表示为UNIX时间戳为86400秒，闰秒不计算。
在大多数的UNIX系统中UNIX时间戳存储为32位，这样会引发2038年问题或Y2038。
2. 时间戳的小故事
1969年8月，贝尔实验室的程序员肯汤普逊利用妻儿离开一个月的机会，开始着手创造一个全新的革命性的操作系统，他使用B编译语言在老旧的PDP-7机器上开发出了Unix的一个版本。随后，汤普逊和同事丹尼斯里奇改进了B语言，开发出了C语言，重写了UNIX，新版于1971年发布。
那时的计算机操作系统是32位，时间用32位有符号数表示，则可表示 68 年,
用32位无符号数表示，可表示136年。
他们认为 以 1970年 为时间 原点 足够可以了。 因此，C 的 time 函数 就这么 定了，后来的 java 等也用它，微机也用它，工作站本来就是unix系统当然也用它。（今后若用64位机年限更没问题。）
32位能表示的最大值是2147483647，另外1年365天的总秒数是31536000，
2147483647/31536000
68．1
也就是说32位能表示的最长时间是68年，而实际上到2038年01月19日03时14分07
秒，便会到达最大时间，过了这个时间点，所有32位操作系统时间便会变为
10000000000000000000000000000000
也就是1901年12月13日20时45分52秒，这样便会出现时间回归的现象，很多软件便会运行异常了。
到这里，我想问题的答案己经出来了：
因为用32位来表示时间的最大间隔是68年，而最早出现的UN以操作系统考虑到计算
机产生的年代和应用的时限综合取了1970年1月1日作为UNTIME的纪元时间（开始
时间）
至于时间回归的现象相信随着64为操作系统的产生逐渐得到解决，因为用64位操作
系统可以表示到292，277，026，596年12月4日15时30分08秒，相信我们的N代子孙，哪怕地球毁灭那天都不用愁不够用了，因为这个时间己经是千亿年以后了。
3. 时间戳有什么用?
说得通俗一些，时间戳就是根据当前系统时间生成的一组随机数字。时间戳一般作为对数据唯一性的一种判断依据。接下来向大家介绍一下我们可以如何运用时间戳。
我们一定会碰到这样的情况：银行A与银行B几乎同时打开你的账户并看到你的账户上原有1000元存款，然后两家银行都想在你的账户上加上500元存款。那么，银行A便将1000元改成1500元，同时，银行B也将1000元改成了1500元。这样就糟糕了！最后，你的银行账户上最后只有1500元而不是理应的2000元，等于白白损失了500元！这就是在没有锁定数据的情况下修改造成的严重问题。然而，我们可以通过时间戳来巧妙解决这个问题。
我们来看思路：
- 在银行account表中建立时间戳字段timestamp，设定为文本类型varchar。
- 当银行A读取account表中的存款字段时，同时也读取时间戳字段，比如123456。
- 当银行A修改完存款数值后，进行存盘操作时，将先前读取的时间戳123456与当时表中的时间戳进行一次对比，如果一致，那么允许存盘，然后生成一个新的时间戳比如456789替换表中原有的时间戳123456。
这样做会带来什么好处呢。
我们再来看一开始的那个情况：银行A与银行B几乎同时打开你的账户并看到你的账户上原有1000元存款，与此同时两个银行业同时读取了时间戳123456，接下来就有区别了，当银行A把1000元改成1500元后，存盘，系统将对比先前的时间戳123456是否与存盘时表中的时间戳一致，显然，现在应该是一致的，那么允许存盘，并生成新的时间戳456789替换了旧的时间戳123456。接下去，B银行也将1000元修改成了1500元，存盘，系统对比先前的时间戳123456是否与存盘时表中的时间戳一致，发现先前的时间戳123456已经与现在的时间戳456789相异，系统拒绝存盘，要求刷新数据，那么数据刷新之后1000元已经因为之前A银行存入了500元而成为了1500元，那么B银行就会在1500元的基础上改为2000元，再次存盘，系统允许。这样，我们就避免了重复修改数据所带来的错误！
4. c语言实现时间戳
