此处本没有文章。催更的人多了，便有了文章。
最近一直沉迷于做另一款浏览器插件，所以写文章的事情又耽搁了下来。
人成长的过程就是不断的完善自己的过程，就如同维护系统一样。
很多问题以前想不清楚，说不定什么机缘巧合就清楚了。
最近（4个月前）有人跑来找我，说Dataloader疯了。
我就好奇啊，好端端的Dataloader怎么就说疯就疯了呢。
那人说了，他遇到的一个问题，
就是导入日期的时候，发现总是差了一天。
比如，tom__c上有一个日期字段date__c，看数据tom1的详细画面，date__c的值为2018-06-29。
然后他把tom1的date__c的值export出来，再update到jerry1的日期字段date__c。
结果在jerry1的详细画面上，date__c的日期少了一天，变成了2018-06-28。
而另一个日期时间型字段datetime__c则没有出现此问题。
肯定事出有因啊。
我就让他看看export的csv文件，里面的日期是啥样的。
咦？date__c是与详细画面一样2018-06-29，而datetime__c则变成了2018-06-28。
然后再update回去之后，在详细画面上看，反而date__c是2018-06-28，datatime__c却是2018-06-29。
结果人家突然一拍大腿，说“我知道了！”，我就很惊诧，这就知道了？
他笃定的说：“这肯定是Dataloader有Bug！我在setting里设置的是东八区，这date型取出来没问题，datetime型取出来却是零时区。这肯定是Dataloder的Bug！我去提票了！”说罢起身就要走。
“且慢！”我赶紧叫住了他。
作为一个成熟的CRM系统，SFDC已经内置了成熟I18N解决方案，以此确保客户全球化的业务可以正常开展。
I18N除了语言的相互翻译，还有包括维护时间的一致性。比如，我在北京早上8点创建一条数据，洛杉矶的的同事应该看到创建时间是昨天的17点，而不是洛杉矶的早上8点。
为了实现这个功能，sfdc在DB中统一存放GMT时间，谁在页面上查看就换算成谁所在的时区。
但是，如果从DB查询（包括Dataloader）的话，是无视任何User个人及Dataloader的时区设定，取出来的是已经换算成零时区的时间。
相反的，不管你所在哪个时区，日期时间都会被换算成零时区之后，才会存进数据库。
所以，由于这个人设定的时区是东八区，CSV文件中datetime__c被减了八小时是正确的。
那么date__c为什么没减八小时呢？这里推测是因为在编辑页面保存的时候，系统会自动补上与时区相等的时分秒，以此保持日期不变。
“这么说的话，那就是update的时候Dataloader出bug了。要不然最后怎么差了一天。”他幽幽的说道。
我摇了摇头。
继续阅读“Dataloader与Timezone”