測量夏令時(DST)轉換前後的持續時間(相對時間段)時,用戶期望


4

我的應用將顯示兩個時間點之間的持續時間。持續時間可以短(例如2小時)或長(例如3週)。我想以友好且易於理解的方式顯示確切的時長,例如" 3天8小時"或" 2小時10分鐘"。

如果在此期間發生DST轉換,應顯示什麼信息?注意:超過一天的時間段必須包含"天"的格式,而不僅僅是" 71小時"之類的小時。

理想的UI可能是如果DST導致一個小時的丟失或增加,例如"一天(由於DST而需要25個小時)"。但我無法控制該UI。我只能決定要顯示的天數,小時數等。這些數字的格式不受我的控制。

我還可以執行Outlook所做的事情(感謝@glorfindel的回答),該方法始終顯示小時數而不是天數,例如從開始夏令時開始為期兩天的" 47小時"。但是,不幸的是,我認為將用戶體驗包括在內的日子會更加清晰,尤其是對於DST開始的周五至週一的" 3天"(而不是" 71小時")之類的較長時段。還有一些技術原因使得很難顯示超過一天的小時數。因此,當整天和更長的時間一起顯示小時和天數時,此問題集中在用戶期望上。

請注意,我故意不將其發佈在Stack Overflow上,因為我對用戶期望感興趣,而不是在知道用戶期望它如何工作後才可以弄清楚的底層算法。我的用戶是消費者,而不是需要極高精確度的專業業務用戶(如空中交通管制員)。我的目標只是報告最合理的持續時間。

我的一般假設:

  • 即使在此期間發生了DST轉換,用戶也希望可以在真實的經過時間中顯示較短的持續時間(例如2小時)
  • 用戶將期望多日持續時間針對DST進行調整。例如,如果在夏令時期間發生了夏令時更改,則在5:00 PM的星期五與下一個星期一的5:00 PM之間的持續時間應始終為" 3天",並且永遠不應為" 3天1小時"或" 2天23小時"。週末。
  • 不管持續時間長短,如果開始和結束之間的日曆時間相同,則結果應始終為整數天數。

我不太確定的情況是DST過渡邊界附近/上的情況,或者時鐘時間不同的1-3天持續時間。您認為在以下情況下用戶會有什麼期望?

這是我不太確定的情況。您認為用戶會有什麼期望?顯然,我要徵求一些用戶的意見,但這似乎是一個已經解決了很多次的問題。您如何看待它解決了?

1-"如果DST在周末開始,則在星期五下午5:00到下一個星期一上午9:00之間的持續時間"

這是非DST週末的2天16個小時。在DST開始的周末我應該顯示什麼?

a)" 2天15個小時"(因為DST損失了1個小時)

b)" 2天16小時"(忽略DST所損失的小時數,只需測量時鐘時間的差異)

2-"如果DST在周末結束,則在星期五下午5:00到下一個星期一上午9:00之間的持續時間"

這是非DST週末的2天16個小時。在DST結束的周末我應該顯示什麼?

a)" 2天17個小時"(因為DST重複了1個小時)

b)" 2天16小時"(忽略DST重複的小時數,只測量時鐘時間的差異)

3-"在DST開始的當天凌晨1:30至第二天的凌晨1:30之間的持續時間

這是現實世界中的23個小時。

a)" 23小時"(因為DST損失了1小時)

b)" 1天"(忽略DST所損失的小時數,只需測量時鐘時間的差異)

4-"在DST開始的當天凌晨1:30到第二天的凌晨3:30之間的持續時間

這是現實世界中的25小時,但時鐘時間為26小時。

a)" 1天1小時"(使用真實時間)

b)" 1天2小時"(使用時鐘時間)

5-"夏令時結束的凌晨1:30到次日凌晨1:30的持續時間

這是現實世界中的25個小時。

a)" 25小時"(因為DST重複1小時)

b)"一天"(忽略DST所損失的小時數,而只是測量時鐘時間的差異)

6-"在DST結束前一天的1:30 AM和第二天的標準時間1:30 AM之間的持續時間

這是現實世界中的25個小時。

a)" 25小時"(因為DST重複1小時)

b)"一天"(忽略DST所損失的小時數,而只是測量時鐘時間的差異)

更多信息

如果您對技術細節感興趣,這是我計劃計算數字的方式:

  • 計算開始日期和結束日期之間的日曆天數,而忽略開始時間和結束時間。如果兩個日期的時間相同,這就是我們的答案。
  • 否則,請計算該時區中開始時間和結束時間之間的實際時差,而不考慮日期和DST轉換。這是要顯示給用戶的小時數(以及分鐘,秒等)。
  • 如果時間差為負,則從第一步中計算的天數中減去一天。現在,這是持續時間中的"整天"數。

我要問的一個大問題是," 計算開始時間與結束時間之間的實際時差"有時需要使用時鐘時間(受DST更改影響)嗎?世界時間(不受DST影響)。

請注意,DST在午夜開始時有一些奇怪的時區,這可能會使事情更加複雜!但是我有信心一旦掌握了用戶的期望,數學部分將變得很簡單。

2

This is how Outlook does it: it uses elapsed time. An event from March 28th 7am to March 30th 7am has a duration of 47 hours (the switch to daylight savings time happened March 29th this year where I live):

enter image description here

This makes sense to me: I'm specifying begin and end time, so I'm thinking in hours. You could show a message somewhere to indicate that the event overlaps with a DST change, and hence the duration may be different from what they'd expect.

Interestingly, if you make it an All-day event, the duration is shown as 71 hours:

enter image description here

Now this is highly confusing; I'd rather opt to hide the time input boxes rather than disable them, and display the duration as '3 days' instead of in hours.