电商产品中多见于秒杀，抢购，生成订单待付款...等限时倒计时。
倒计时看起来很简单，其实也很简单。
逻辑就是---->从未来的某个时间节点开始计算 ，距离当前时间节点的差值以时分秒的形式展示在UI上。</br>
以我碰到的问题为例
1. 这是一个O2O的电商项目，其中有一个模块的小功能就是下单后，
两个小时内必须付款，不然订单作废（需要重新下单）
2. 需要搞一个倒计时提示用户，以免错失最佳付款时机
如何开展：
首先得记录一个时间节点，就是下单的时间，
根据推算，倒计时时长两个小时，
那就是下单后的两个小时的时间开始往下计算，
使用UserDefaults记录这个时间，后面取出来与当前时间（转化为时间戳） 相减计算，
然后进行UI的更新
### error
我一开始存储的不是下单时的当前时间，
而是服务端请求返回的时间戳，结果以计算有5分钟以内的误差
，感觉不太对，思考之后发现应该是下单那一瞬间的时间戳
存储在本地就可以的，拿服务端返回的时间戳总会有点误差，
还是存之本地，取之本地，用之本地，这样才是准确的。
###error 错误升级了,原来不是服务端与本地的问题
服务端可能会产生延时,但是我是存取了延时后的结果,
➕上两个小时的计算毫无影响.
真正的原因是计算出了问题,时间戳本来应该是double类型,
改了个别名而已`typedef double NSTimeInterval
`
所以一开始我是用的floatValue来计算的 ,结果偏小,因为丢失精度了
后来我意识到了这个丢失精度的问题,转而使用double结果偏大;
后来才发现时间戳的标准取值是取到整数位也就是秒, 格式符号为 %.0lf
NSDate* date = [NSDate dateWithTimeIntervalSinceNow:0];
NSTimeInterval stamp=[date timeIntervalSince1970];
NSString *timeString = [NSString stringWithFormat:@"%.0lf", stamp];
NSLog(@"timeString=%@", timeString);
NSLog(@"----%f",[NSDate date].timeIntervalSince1970);
###consoleLog: 看看👀控制台打印
2016-10-11 09:43:33.099 测试[18086:685165] timeString=1476150213
2016-10-11 09:43:33.100 测试[18086:685165] ----1476150213.100050
###这个故事告诉我们,错误是尝试过才被发现的,问题是需要一步一步解决的✅ 狠狠的装一波! :)
*iOS中一般都先转化成时间戳即总的秒数（距离1970年） *
不明智的行为：
和产品PK需求是一件多么浪费生命的事儿，他主观地认为他的逻辑和审美是对的，从来不结合用户的体验如何，交互如何，实现起来如何。。。一旦某天，某猿一时兴起，跟他讨论一个需求的问题，无论对错，他总能找到理由说服，然后讨论的时间过去了，却没有任何改变，然并卵。 这是一件浪费生命的事儿，虽然平时开会怎么说要有自己的想法，提出建设性的意见和建议，呵呵，不过是做做样子罢了，谁要是被说服了，可能会被人怀疑自己的产品设计能力和审美，再加上是一个小年轻的程序员，有多年的产品经理岗位经验的人自然也有很重的自尊心，凭啥要听你一个 门外汉指手画脚（据说是隔行如隔山。。。。） 。。。好啦 吐槽完毕！ 早点睡觉，明天起来又是满满的正能量，继续挑战产品的底线！！！ 活着就是要有自己的想法，不然还不如猝死得了！哈哈：）
（PS丶写下这篇文字，无非就是提醒自己少犯错，多思考之后还是可以拎得清楚的。主要是太久没有写过作文了，写篇记录都显得格外吃力，就想一口气把所有的问题一股脑儿的倾泻而出的感觉，可惜词穷，感觉在凑齐500个字作文就可以及格似的。。。。：）
于2016年10月10日 勉励现在菜得抠脚的自己
