12/18/2023 0 Comments Strange note durationsUsers will expect multi-day durations to adjust for DST.2 hours) to be shown in real-world elapsed time, even if there was a DST transition during the period Users will expect short durations (e.g.My goal is simply to report durations that seem most reasonable. My users are consumers, not specialized business users like air traffic controllers who need extreme precision. 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. So this question is focused on user expectations when showing hours and days together for daylong and longer periods. There are also some technical reasons that make it difficult to show only hours for periods longer than one day. 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. "47 hours" for a two-day period that spans DST starting. I could also do what Outlook does (thanks for the info in his answer) which is always display hours instead of days, e.g. The formatting of those numbers is not under my control. I can only decide a number of days, hours, etc. The ideal UI is probably to show a note to the user if DST causes an hour to be lost or gained, e.g. 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". "3 days and 8 hours" or "2 hours and 10 minutes". I'd like to show the exact duration in friendly, human-readable terms, e.g. My app will show a duration between two points in time.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |