由来
那时候还很无知，虽然发现了有这么一个用户体验不错的细节，可惜开动了小脑经也并不知道怎么玩的。
场景
地点：新浪微博 事件：发现每条微博的时间都会不断的自己变咧！这样就算你放了N久，也会知道这条微博是到底什么时候发的，不用再去刷新页面了。
问题
是怎么能实现批量更新时间的呢？ 通常都是在服务端查询后根据时间算出对应的人性化时间，“几秒前”“*分钟前”等等。 而这样的字符串是很难再哪来二次计算的。
分析
上面是时间的代码片段，简单看一下，跟时间有关系的属性，只有title，date，node-tpye,这三个属性：
title从值看来是年月日时分的格式化后的字符串date时间戳node-type从值来看应该算是表示了某一类的类名
通常来讲，用时间戳来计算是最方便的，因为他是以毫秒为单位，而天、时、分、秒都可以用毫秒来表示，而超过了某个单位的最大值，比如一分钟前的微博，用现在的时间戳减去之前的时间戳，大于60000毫秒的话，那么肯定就是一分钟前了。
而找到这些元素只需要通过找到node-type属性为feed_list_item_date的元素再获取date属性计算后改变即可。
这里我是尝试了一下把feed_list_item_date改为feed_list_item_date1他的时间就不变了，而其他的已然在周期性的变化，改回去之后又在周期的变化。
补充
然而有个事被我差点忘记了，就是这个title属性，为毛没有讲是干啥用的，我开始也没想明白，而后来我看到了这个
我好像有点明白了，我又观察了一下，在一个小时内，时间是会显示xx分钟前的，但是超过了一个小时之后，时间就会变成今天 13:00, 昨天 13:00，8月20日 13:00这个样子了，那么这个title感觉很好解释了，超过1小时候拿这title来替换掉其中的yyyy-MM-dd部分，就成了稍微久远点的人性化时间。
总结
其实一些不错的产品很值得琢磨的，不管是用户体验也好，优化也好