User expectations when measuring durations (relative time periods) around Daylight Savings Time (DST) transitions
My app will show a duration between two points in time. Durations can be short (e.g. 2 hours) or long (e.g. 3 weeks). I'd like to show the exact duration in friendly, human-readable terms, e.g. "3 days and 8 hours" or "2 hours and 10 minutes".
If there's a DST transition during the period, what information should be shown? Caveat: periods longer than one day must include "day(s)" in the format, not only hours like "71 hours".
The ideal UI is probably to show a note to the user if DST causes an hour to be lost or gained, e.g. "one day (25 hours thanks to DST)". But I don't have control over that UI. I can only decide a number of days, hours, etc. to show. The formatting of those numbers is not under my control.
I could also do what Outlook does (thanks @glorfindel for the info in his answer) which is always display hours instead of days, e.g. "47 hours" for a two-day period that spans DST starting. But unfortunately I think it'd be clearer user experience to include a number of days, especially for longer periods like "3 days" instead of "71 hours" for Friday->Monday on the weekend that DST starts. There are also some technical reasons that make it difficult to show only hours for periods longer than one day. So this question is focused on user expectations when showing hours and days together for daylong and longer periods.
Note that I deliberately didn't post this on Stack Overflow because I'm interested in user expectations, not the underlying algorithm that I can figure out once I know how users expect it to work. My users are consumers, not specialized business users like air traffic controllers who need extreme precision. My goal is simply to report durations that seem most reasonable.
My general assumptions:
- Users will expect short durations (e.g. 2 hours) to be shown in real-world elapsed time, even if there was a DST transition during the period
- Users will expect multi-day durations to adjust for DST. For example, the duration between Friday at 5:00PM and the following Monday at 5:00PM should always be "3 days" and never "3 days and 1 hour" or "2 days and 23 hours" if a DST change happened over the weekend.
- Regardless of duration length, if the calendar time is the same between start and end, the result should always be an integer number of days.
The cases that I'm less sure about are ones near/on the DST transition boundaries, or 1-3 days durations where the clock times differ. What do you think users would expect in the cases below?
Here's the cases I'm less sure about. What do you think users will expect? Obviously I'm going to ask some users for their opinions, but this seems like a problem that's been solved many times before. How have you seen it solved?
1 - "Duration between Friday at 5:00PM and the following Monday at 9:00AM, if DST starts over the weekend"
This is 2 days and 16 hours on a non-DST weekend. What should I show on a weekend where DST starts?
a) "2 days and 15 hours" (because 1 hour lost to DST)
b) "2 days and 16 hours" (ignore hour lost to DST and just measure the difference in clock time)
2 - "Duration between Friday at 5:00PM and the following Monday at 9:00AM, if DST ends over the weekend"
This is 2 days and 16 hours on a non-DST weekend. What should I show on a weekend where DST ends?
a) "2 days and 17 hours" (because 1 hour repeated by DST)
b) "2 days and 16 hours" (ignore hour repeated by DST and just measure the difference in clock time)
3 - "Duration between 1:30AM on the day that DST starts and 1:30AM on the following day
This is 23 hours in the real world.
a) "23 hours" (because 1 hour lost to DST)
b) "1 day" (ignore hour lost to DST and just measure the difference in clock time)
4 - "Duration between 1:30AM on the day that DST starts and 3:30AM on the following day
This is 25 hours in the real world, but 26 hours of clock time.
a) "1 day and 1 hour" (using real world time)
b) "1 day and 2 hours" (using clock time)
5 - "Duration between 1:30AM daylight time on the day that DST ends and 1:30AM on the following day
This is 25 hours in the real world.
a) "25 hours" (because 1 hour repeated by DST)
b) "one day" (ignore hour lost to DST and just measure the difference in clock time)
6 - "Duration between 1:30AM on the day before DST ends and 1:30AM standard time on the following day
This is 25 hours in the real world.
a) "25 hours" (because 1 hour repeated by DST)
b) "one day" (ignore hour lost to DST and just measure the difference in clock time)
More Info
If you're interested in the technical details, here's how I'm planning to calculate the numbers:
- Calculate the number of calendar days between the start and end dates, ignoring start and end times. If the times are the same on both dates, this is our answer.
- Otherwise, calculate the real-world time difference between the start and end times in that time zone, ignoring the dates and ignoring DST transitions. This is the number of hours (and minutes, seconds, etc.) to show to the user.
- If the time difference is negative, subtract one day from the number of days calculated in the first step. This is now the number of "full days" in the duration.
The big question I have is whether "calculate the real-world time difference between the start and end times" sometimes needs to use clock time (which is affected by DST changes) instead of real-world time (which is not affected by DST).
Note that there are weird time zones where DST starts at midnight, which might complicate things even further! But I'm confident that once I have a handle on user expectations, the math part will be straightforward.