目前，在我們的 Laravel 應用程序中，我們將時區設置如下。 'timezone' => env('TIMEZONE', 'Europe/London'),我們 MySQL 數據庫中的所有DateTime和timestamps字段也存儲在Europe/London時區中。我們的應用程序現在將切換到UTC，但是如果我們在我們的應用程序中更改到，目前還有一個小時，我們所有現有的基礎設施都會中斷BST。TIMEZONEUTC將中斷的事情包括我們現有的使用時間字段的查詢，因為它們將與數據庫中的記錄不同步一個小時。下面是我們在系統查詢中使用時間的示例Task::where('expired', '=', false)->where('expires_at', '<', Carbon::now())->get();使用上面的代碼示例，任務將提前一個小時到期，因為UTC晚了一個小時BST。由于更改為UTC將是系統的根本變化，我希望我能得到以下問題的答案。是否有任何資源概述了將系統從本地時區轉換為 UTC 的方法？UTC我應該將所有內容都存儲起來，Europe/London然后在前端為用戶轉換，而不是轉換為嗎？有什么方法可以輕松查詢其中包含多個時區的數據庫表？感謝您的幫助，我知道這個問題很難，所以任何能指出我正確方向的東西都將不勝感激。
1 回答
侃侃無極
TA貢獻2051條經驗 獲得超10個贊
不能說你列表中的第一項，這是我對第二項的看法。實際上有很多時區你應該知道：默認的 php 時區（來自 php.ini 的那個），服務器時區（afaik，如果 php.ini 時區是空的，它會回落到服務器的那個），mysql 的時區，部署mysql實例的服務器時區，你當前所在的時區，你用戶的時區，更不用說像mysql連接時區這樣通俗的東西了。
話雖如此，如果您不想在調試花哨的錯誤時度過一段愉快的時光，那么您希望所有系統時區都相同。實際上，它到底是什么并不重要。更重要的是，您了解它們中的每一個，并且知道它們如何適用于您的情況。將所有系統時區設置為 UTC 只是更可預測、更通用、更常見。
但如果我是你，我會保留基礎設施時區設置不變。我懷疑你從這一舉措中獲得了什么有形的東西。在前端轉換日期時間實際上是處理此類問題的常用方法。例如，在 postgres 中，可以將時區與日期時間一起保存，但它幾乎沒有用，因為它已轉換為系統時區。所以當我需要向客戶端輸出日期時間時，我會寫類似
(new AdjustedAccordingToTimeZone(
? ? new FromISO8601('2018-04-25 15:08:01+00:00'),
? ? new Moscow()
))
? ? ->value();
關于你的第三個問題，如果您查詢多行，每一行都有自己的時區，您可以隨時將這些日期轉換為您希望的任何時區。
- 1 回答
- 0 關注
- 261 瀏覽
添加回答
舉報
0/150
提交
取消