2015-06-22 90 views
1

我有一個簡單的移動應用程序,用於安排指定位置的人員之間的未來事件。這些事件可能是物理的或虛擬的,因此爲事件指定的時間可能不會與與事件的「位置」處於相同的時區。例如,當地時間上午10點在指定日期倫敦的兩個人可以安排實際會議。另外,雖然事件的「地點」僅僅是「辦公室」,這意味着在不同的時區有兩個不同的地方,但可以在特定的日期在下午4點(在一個人的時區)在不同的時區爲兩個人安排Skype呼叫。提供UTC時間戳可用時區信息是否冗餘?

我不知道下面的設計是要爲這個應用程序的工作:

  1. 在客戶端,它會要求用戶輸入本地日期和時間,並指定時區本地的事件。

  2. 在服務器上,它將提供的時區的本地日期和時間轉換爲UTC時間戳,並僅存儲此時間戳。

  3. 當客戶端檢索到這些詳細信息時,它僅接收UTC時間戳,並將其轉換爲與客戶端當前時區相同的時區中的本地時間。客戶端的當前時區由當前系統時區設置決定,我認爲該時區根據客戶端的位置自動調整(當然,假設客戶端連接到移動網絡)。

我對這種設計的主要動機是:

  1. UTC是一個絕對的和普遍的時間標準,你可以從它轉換到/自/至任何時區。

  2. 用戶只關心本地日期和時間的時區,他們目前英寸

這是一個可行的設計?如果不是,哪些特定情況會破壞應用程序或嚴重影響用戶體驗?批評表示歡迎。

回答

3

對於單個事件,只要你有正確的UTC時間(見後面),就知道它發生的UTC時刻就足夠了。

對於重複事件,您需要知道它重複的時區...不只是UTC偏移量,而是實際時區。例如,如果我安排在歐洲/倫敦下午5點與美國/洛杉磯的同事每週舉行一次會議,那麼對於年的大多數,它將在上午9點發生,但對於他們來說,但是在一年中的幾個星期內,將在上午8點發生,並且在上午10點發生幾個星期,這是由於觀察到DST時的差異。

即使對於單個事件,您也可能想要考慮如果時區規則更改會發生什麼情況。假設我在2018年3月20日下午4點在歐洲/倫敦時區安排會議。 當前將在UTC時間偏移爲0的情況下發生......但假設在現在和會議之間,時區規則將更改爲在一小時之前提前提供英國夏令時。如果我在下午4點將它寫入日記本中,我可能不希望軟件認爲它實際上是在下午5點,因爲這是我們最初預測的UTC時刻。

我們不知道您的具體應用需求,但上述情況至少爲潛在參數存儲在本地時間和時區,而不是UTC瞬間......但你也需要如果當地時間由於DST變化而被跳過或變得模糊不清,該怎麼辦? (當時鍾倒退時,一些當地時間出現兩次,當時鍾向前跳過時,一些當地時間被跳過,如果規則在原始計劃時間和實際事件之間改變,那麼明確的的時間可能變得無效或不明確你或許應該在設計中考慮到這一點)

1

爲了簡單起見,我的答案是:如果要定義一個時刻

  • 時區信息是多餘的。 UTC/Unix時間戳完全定義了一個時刻。
  • 您的設計似乎是可行的,但在第2點上:我將轉換爲客戶端的UTC/Unix時間戳,並且已將其時間戳 以其最終形式提供給服務器。原因:客戶端已經有必要進行轉換的信息(請參閱此time-keeping client-server-db architecture 示例 - 它的工作原理完全基於您描述的原則)。

  • 一個可能的問題(正如Jon Skeet在他的回答中所描述的)是經常性事件,但這應該反映在您建模 時間的方式中。重複事件和固定事件之間的差異是 ,後者完全定義了一個時刻(如UTC/Unix 時間戳),而第一個只是一個'功能',可以將 應用到當前時間以獲得下一個觸發時間的經常性事件 事件。但是,這可能完全是一個與您所問的問題完全不同的問題 - 無論如何,以某種方式區分重複發生的 事件(如果您需要它們)和模型中的固定事件是一個很好的想法。

  • 做出的一個決定是:PULL還是PUSH?或兩者?例如,當事件發生到 通行證時,您是否希望服務器能夠發送電子郵件?或者只有在客戶端 應用程序正在運行時才需要客戶端警報?這些問題的答案將有助於您將 推向適合您的設計。