如果我們需要去做時間的國際化，那么肯定存在這樣一種情形，即，在絕對時間同一時刻， 但這個時刻在數據庫的存儲的值是同一個值，在北京和在紐約看到的時間顯示是不同的。
看過網上的一些方案，基本認為是兩種基本方案，一個是直接傳輸給前端Long 類型的時間戳，再由客戶端獲取當地的時區來進行時間的顯示。另一種則是傳輸給前端一個UTC Epoch，類似于這樣的字符串-- "gmtModified":"2021-08-20T09:57:16.000+0000"。表示的是某一個時區的時刻，如上面這個字符串，就是表示零時區21年08月20號上午09時57分16秒。
我的意見更加偏向于后者，主要是考慮到Long類型的時間戳存在以下一些問題。
1.如果需要對時間進行基本的運算，如加減一個月，或者7天，Long類型的運算多是數學的加減法，代碼可讀性低，也容易產生錯誤。如果將時間戳換算成時間對象去計算的話，就產生了轉換的成本，而這個成本是可以避免的。
2.調試時，光看時間戳，開發人員不會產生時間的認識，在開發人員眼中，兩個不同的時間戳的數字，只是代表了兩個不同的時刻，減少了相對時間的認識。例如，相差多少時間，這兩個時間戳分別表示的是什么時候。

較為完整的解決方案：
Mysql 數據庫之中存儲的時間都是零時區的時間，因為要保證服務端的時間格式一致性。現在每一個mysql的連接，即我們的服務對mysql的連接，對于整個系統來說，仍屬于服務端的范疇，但是對于mysql而言，我們的服務是mysql的客戶端，所以我們的服務的每一個數據連接都需要顯示的設置時區參數。我們目前用的就是東八區，所以，時間在我們服務端的流轉也統一使用東八區為宜。
時區的轉換一般發生在序列化和反序列化的時候發生，目前來說，只要保證每次序列化和反序列化都按東八區來進行就不會有問題，即需要保證各個服務的時區一致性。
傳輸給前端的VO需要改變一下序列化策略，應該采用UTC epoch的格式給前端。跟目前的服務端的傳輸的時間格式相對比的話，就是多了一個時區的信息。
當然，前端傳輸的數據也應該是時間戳或者UTC epoch。

存在的一些問題：
上面的方案也不是完整的，存在一個問題。即服務端各個服務之間需要遵從同一個時區，如果只是時間的相對運算，例如三天后，8小時候后，一周之后，這個不會有問題，因為每一天都是固定的24小時，每個小時都是固定的60分鐘。但是如果是一個月之后或許會有不同，或者是當月有效亦或者11.11當天有效這些判斷條件。原因是因為服務端需要保證時區的一致性，而如果客戶端是國際化的，那么服務端都以一個時區為準，而客戶端是多時區的。在北京的11.11號，和紐約的11.11號是不同的。
在這種情形之下，服務端如果進行時間的計算應該僅限于固定時間的偏移，例如，10s之后，10分鐘之后，10小時之后，10天之后。而也會有一些特殊的情況，具體的情形有，年費的會員，怎么計算過期的問題，我看過一種方案，一種是直接取對客戶有利的值，即366天,計算的時候在開始的時間戳上加上366天就可以了。
另外一種情況是雙十一，這種屬于浮動時間，我覺得應該以服務端的時區為準，因為計算發生在服務端之上。即活動通知時，就應注明活動時間為北京時間11月11號，黑色星期五則應以紐約時間黑色星期五為準。

總結

以上是生活随笔為你收集整理的关于时间国际化的方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。