因為做的是global項目,會遇到一些因為時區(qū)產(chǎn)生的問題.特此總結一下
匯總
- Android 設備拿到的String格式轉換后會默認使用當前設備的timezone.
常見問題處理方法:SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss") .parse("2021-06-01T10:10:10.000Z")
- 結果(假設JVM當前時區(qū)--中國時區(qū)
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時間,因為解析的時候被抹掉了時區(qū)信息,就會默認是JVM當前時區(qū)的時間.所以會有問題,少了8個小時. - 解決辦法
方法1. 添加上時區(qū)信息.
方法2. 指定轉換時區(qū)SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX") .parse("2021-06-01T10:10:10.000Z")
方法1好處:無論傳什么時區(qū)的date都可以處理,SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss") .apply { this.timeZone = TimeZone.getTimeZone(ZoneOffset.UTC) } .parse("2021-06-01T10:10:10.000Z")
方法1缺點:如果有些api傳的格式不一樣,例如毫秒少了個0,或者沒有毫秒信息,會thorw解析error
方法2好處:無論傳什么樣的格式,解析都不會出問題,除非太夸張
方法2好處:只能解析統(tǒng)一時區(qū)的時間,如果是多個時區(qū)過來,就會解析出錯.
請根據(jù)實際情況,選擇不同的方法.
- 結果(假設JVM當前時區(qū)--中國時區(qū)
- 如果后臺傳的時間不是JVM當前時區(qū)的時間,建議使用
string
去承接后再做解析,不要使用date去做解析,容易出bug. 部分手機設備會切換完timezone后直接更改APP里面的時間,這樣子的話,用date
會有問題.
Ps: 如果用date
格式,之后打算在gson
那里配置好時間格式yyyy-MM-dd'T'HH:mm:ss.SSSX
.需要前后臺格式上做好配合,而且某個api不是那種格式就比較容易轉換失敗,要慎重!!