因为做的是global项目,会遇到一些因为时区产生的问题.特此总结一下

汇总

1. Android 设备拿到的String格式转换后会默认使用当前设备的timezone.
   常见问题处理方法:

     SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss")
       .parse("2021-06-01T10:10:10.000Z")
   

   1. 结果(假设JVM当前时区--中国时区GMT+8):
      Expected : Tue Jun 01 18:10:10 GMT+08:00 2021
      Actual: Tue Jun 01 10:10:10 GMT+08:00 2021
      因为后台传的是UTC时间,因为解析的时候被抹掉了时区信息,就会默认是JVM当前时区的时间.所以会有问题,少了8个小时.
   2. 解决办法
      方法1. 添加上时区信息.

      SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX")
          .parse("2021-06-01T10:10:10.000Z")
      

      方法2. 指定转换时区

      SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss")
          .apply { this.timeZone = TimeZone.getTimeZone(ZoneOffset.UTC) }
          .parse("2021-06-01T10:10:10.000Z")
      

      方法1好处:无论传什么时区的date都可以处理,
      方法1缺点:如果有些api传的格式不一样,例如毫秒少了个0,或者没有毫秒信息,会thorw解析error
      方法2好处:无论传什么样的格式,解析都不会出问题,除非太夸张
      方法2好处:只能解析统一时区的时间,如果是多个时区过来,就会解析出错.
      请根据实际情况,选择不同的方法.
2. 如果后台传的时间不是JVM当前时区的时间,建议使用string去承接后再做解析,不要使用date去做解析,容易出bug. 部分手机设备会切换完timezone后直接更改APP里面的时间,这样子的话,用date会有问题.
   Ps: 如果用date格式,之后打算在gson那里配置好时间格式yyyy-MM-dd'T'HH:mm:ss.SSSX.需要前后台格式上做好配合,而且某个api不是那种格式就比较容易转换失败,要慎重!!