再也不用long了！！！
之所以发出这样的感慨。是因为最近被long坑了。
用户行为分析被报两次服务器和本地时间戳记录不正确的问题。
接到问题反馈以后，脑子里先出现了几种导致该问题的可能性
1、服务器时间返回有问题?
处理结果：测试过程中未复现，无从查证。
2、没有处理获取服务器时间接口报错的问题导致?
处理结果：将接口返回错误的情况进行处理。
经验证，实际上即使接口报错也并不会导致此问题，因为本地时间戳和服务器时间戳这两个变量都有传默认值，也就是本地时间。所以当初没有做这里的处理。
3、服务器时间计算出问题？
处理结果：重新捋了一下代码，并没有发现问题所在。
4、时间戳有溢出？
处理结果：依旧没有复现，不过将ClientTimeStamp和ServerTimeStamp变量类型由long改为long long以防万一。
进一步定位：
经查得出结论。确实是由于32位机型和64位机型的long整型最大值不同导致的。我忽略了32位处理器的long整形的最大值和int值一样，都是2147483647
unsigned int 0～4294967295
int -2147483648～2147483647
unsigned long 和int一样
long 和int一样
long long的最大值：9223372036854775807
long long的最小值：-9223372036854775808
unsigned long long的最大值：1844674407370955161
__int64的最大值：9223372036854775807
__int64的最小值：-9223372036854775808
unsigned __int64的最大值：18446744073709551615
64bit下
unsigned int 0～4294967295
int -2147483648～2147483647
unsigned long 和 unsigned long long一样
long 和long long一样
long long的最大值：9223372036854775807
long long的最小值：-9223372036854775808
unsigned long long的最大值：1844674407370955161
__int64的最大值：9223372036854775807
__int64的最小值：-9223372036854775808
unsigned __int64的最大值：18446744073709551615
最后再次确定结论：
查询用户行为分析日志发现。出现时间戳不正确的机型为iphone5和ipad mini1，这两款机型都是32位处理器，怪不得手里的机器一直复现不了。第二步，翻看时间戳错误的记录，所有的ClientTimeStamp都是2147483647，溢出后的最大值。再次证实这一结论。
所以，以后建议大家，遇到处理时间戳（毫秒级）或者你不确定返回数值有多大的情况。一定要用long long型，避免带来不必要的麻烦。
在32位系统中
int 占4个字节
long 占4个字节
NSInteger 是int的别名，占4个字节
long long 占8个字节
int32_t 是int的别名，占4个字节
int64_t 是long long的别名，占8个字节
在64位系统中
int 占4个字节
long 占8个字节
NSInteger 是long的别名，占8个字节
long long 占8个字节
int32_t 是int的别名，占4个字节
int64_t 是long long的别名，占8个字节
