15

There is a proposal on Meta Stack Exchange to add the day of the week to the hover-texts for timestamps on Stack Exchange, which currently show a raw UTC timestamp, of the form YYYY-MM-DD HH:MM:SSZ, where the 'Z' is a literal that indicates that it is a UTC timestamp.

enter image description here
screenshot used in the MSE proposal, by rolfl

The context, of course, is an online event in a system used around the world. The timestamps are used by various people for various purposes. Some uses, as highlighted in the MSE proposal, require determining the local day of the week associated with the timestamp.

There was discussion in the comments about whether prepending the day of the week, yielding, e.g., Mon 2015-01-26 09:22:17Z, would be, on balance more helpful or more harmful.

  • Helpful: Allows the viewer to see, at a glance, what day of the week (UTC) the event occurred on. The viewer can translate from UTC to another relevant time zone and, in the process, determine whether to adjust the day of the week along with the hour and date.

  • Harmful: Makes it more likely that a viewer interested in the day of the week will miss the fact that it's a UTC timestamp and will take the shown day of the week as valid.

In such a context, should UTC timestamps include day of the week or not?

Is there UX literature, or are there standard UX design principles that address this question?

10
  • 1
    @CodeMaverick, thanks. I mistakenly took the title of a related question as inspiration; I should have revisited the title after writing the body, as you did. Jan 27, 2015 at 19:24
  • 1
    No worries - I got your back! I knew what you meant. Jan 27, 2015 at 19:40
  • Note that this question assumes that it's a nice-to-have feature, and that people don't need to know what day-of-week a date happened on. That assumption is not true. There are reasons why knowing the DoW is essential, and thus the question should be: "How do you best present the DoW when you have a UTC date", not "whether you should present the Day-of-week".
    – rolfl
    Jan 27, 2015 at 20:29
  • @rolfl, I thought I presented the "Helpful" case pretty accurately. If I didn't, I'm open to suggestions. I'd note, though, that "knowing the DoW is essential" is a different claim than "presenting the DoW is essential." The former could be true (And I agree that there are situations in which it is!), with the best practice still being to present a raw timestamp and let the user know the DoW by deriving it from that. Jan 27, 2015 at 20:32
  • @IsaacMoses - you signed up here on 2011-08-30 21:32:44Z. That's just a date, but, what day of week was it. How would you find out? You say you can: with the best practice still being to present a raw timestamp and let the user know the DoW by deriving it from that. Is there an easy way that I am missing?
    – rolfl
    Jan 27, 2015 at 20:44

5 Answers 5

21

Timestamps aren't meant for most users

Showing friendly names such as 2 hours ago or yesterday can quickly provide context to the user as opposed to showing them 2015-01-27 18:54:03.259 Mixing both formats together will always cause friction (anything that forces a user to ask a question in their mind adds to cognitive friction). In almost all cases mixing them will do more harm than good so leave off the day of week. Even at the expense of providing context, there should be no question that what I'm looking at is a timestamp.

While friendly date formats are better displayed in the UI by default, timestamps should be hidden until a user requests it (such as hovering the mouse over a displayed date/time or changing a setting)

Friendly names such as the ones used in Outlook provide better context than Monday or Friday. The names for each day of the week loses context every 7 days. Saying Tuesday today might help a little but saying Tuesday next week would be confusing even without bringing timestamp in to the mix...

enter image description here

8
  • 4
    Note that, on Stack Exchange, especially as a moderator, it is often critical to know things like "who answered first", and, for that, you need to check the timestamp, because if one person answered "1 day ago", and the other person answered "1 day ago", there's no way to tell. Sometimes friendly formats are not useful. This answer does not address the actual question, it just says the questions assumptions are not relevant to other situations.
    – rolfl
    Jan 27, 2015 at 21:42
  • 1
    Dave, while that would be useful, it also relates to all sorts of timestamps on Stack Exchange, like accounts in vote-rings/sock puppets, suspension notices, moderator activities, comments, chat messages, second, third, and forth answers, answers on different questions, etc. While you are right, a "answered first" icon may be nice, it is also not the point.
    – rolfl
    Jan 27, 2015 at 22:00
  • 1
    @rolfl why should you be looking at an UTC timestamp? It makes sense for the timestamp to be stored and used in code as UTC, but as soon as it gets shown to a user it would be best shown according to the locale and timezone of the viewer.
    – Peteris
    Jan 27, 2015 at 22:00
  • 1
    "leave off the day of week" is a valid answer to "How do you best present the DoW when you have a UTC date?"
    – DaveAlger
    Jan 27, 2015 at 22:02
  • 2
    @rolfl the question is about "hover-texts for timestamps ... which currently show a raw UTC timestamp". Changing the hovertext to local-time+weekday is a reasonable alternative to the proposed hovertext of UTC+weekday.
    – Peteris
    Jan 27, 2015 at 22:03
5

Displaying the day of the week (e.g. Monday, Tuesday) usually only makes sense when the date is either recently passed (i.e. within the last week) or in the future. When a date has recently passed, stating the day of the week makes it easier to recognise within that limited context. For future events, knowing on what day of the week it's due to take place is more useful than having to consult a separate calendar.

For something that happened several weeks, months or years ago, there is little value in explicitly stating the day. I think that holds true with questions on Stack Exchange. I don't see any real value in adding that extra information and I can see some opportunity for it to cause confusion with timezones.

3
  • I completely disagree with the assertions you make here. The core assumption is that the user needs to know the day-of-week for a date, and it is the reverse of what you say. Being able to mentally calculate the Day from a recent date is easy, but being able to do it for a long-past date is very hard. It is exactly when the date is in the distant past or future that the timestamp should include the day.
    – rolfl
    Jan 27, 2015 at 21:46
  • 2
    @rolfl can you elaborate on why "The core assumption is that the user needs to know the day-of-week for a date" ? The default reason for including the weekday is because for many people "last wednesday" is more accurate than 21st february - they may be mistaken that last wednesday was, say, 20th february and pick a wrong date. There may be niches where it's important to know the week of day for an event in long past (e.g. transportation scheduling apps, industry/sales data with strong weekly patterns) but then this requirement will appear from the domain details, not general UX practices.
    – Peteris
    Jan 27, 2015 at 22:10
  • What @Peteris said.
    – Matt Obee
    Jan 27, 2015 at 22:23
1

The Question's Title (repeated in the body too) is :

Should UTC timestamps include day of the week or not?

The answer is "it depends":

  1. If humans don't need to know the Day-of-Week for a timestamp, then No.
  2. If humans do need to know the day-of-week for the timestamp, but they can have the date processed for them order to determine the day-of-week, then no, the base timestamp does not need it.
  3. If humans do need to know the day-of-week for the timestamp, and the process for computing that information would be manual, or time-consuming, then having it embedded in the timestamp would provide a much better user experience.
  4. If no humans are involved, there's no need to include the Day-Of-Week.

That's the basic answer to the core question.

The question divides the components of the feedback in to 'helpful' and 'harmful':

  • helpful: Allows the viewer to see, at a glance, what day of the week (UTC) the event occurred on

    That's the whole idea. The user needs to know the day, so telling them at a glance is surely helpful.

  • harmful: Makes it more likely that a viewer interested in the day of the week will miss the fact that it's a UTC timestamp and will take the shown day of the week as valid

    That's a bigger UX item than the focus the day-of-week only. There's already confusion about the UTC timestamps, and users who 'hover' over those timestamps are mostly (all?) already familiar with the fact that it is in UTC. Adding the Day-of-week will not make those users any more confused. It is not the DayOfWeek that makes the timezone confusing, but the UTC itself. Additionally there are other reasons why UTC is/was chosen, and those reasons are beyond the scope of this question/answer.

    Bottom line, no, adding the day-of-week will not make it any more confusing than it already is. Many people miss that the timestamps are UTC already, and that's a different UX problem.


Applying that logic to the example provided in the meta.se question:

  • there's a timestamp
  • there's a human element
  • there's a need to know the day-of-week for the timestamp
  • the system does not allow an easy, or automatic ability to present the Day-Of-Week for the date.

For the situation described in the meta question, the right answer would be to include the Day-of-week in the timestamp.

An interesting User Experience question would be where in the timestamp, but that is not what this UX question asks.


The tail of the question is:

Is there UX literature that addresses this question, or are there standard UX design principles that do?

The basic question is: A user needs to know the Day Of Week for a date, the US Government has a website tailored for Usability: www.usability.gov and it has the following key components for usability:

Honeycomb basics

image in public domain, but credited to Peter Morville

Where the 'Usable' aspect is defined as "Site must be easy to use", and the 'Findable' aspect is defined as "Content needs to be navigable and locatable onsite and offsite"

Making the required information (day of week for a date) only available 'off-site' is clearly a violation of the Usability and Findability aspects.

6
  • @IsaacMoses - there are three actual questions in the question, one in the title, and 2 in the body. The title question and the first body question are identical. The third question is asking for literature. Which question was missed by this answer?
    – rolfl
    Jan 27, 2015 at 22:03
  • The argument in this answer seems to be "This information is needed by some users in this context and is not otherwise trivially available. Therefore UX principles say it must be included." That argument could be applied to require almost any information to be included almost anywhere. What limiting principle would you apply to keep that from being the case? Jan 27, 2015 at 22:08
  • Exactly... you got it. The UX problem at the moment is that the required information is not trivially available, and, instead offering helpful suggestions about how to make it available in a UX friendly way, all the answers (and in fact this question itself), have made the (erroneous) presupposition that the information should not be required to start with. The timestamp in the hover-text context is just fine, and even UTC is OK, all that's missing is a DoW. Those are almost optimal UX elements... just missing one little day-of-week.
    – rolfl
    Jan 27, 2015 at 22:13
  • I don't see how this question makes any presupposition about how required the information is. Jan 27, 2015 at 22:16
  • @IsaacMoses - The entire title and main question makes the wrong presupposition (that the day is merely a nice-to-have): "should UTC timestamps include day of the week or not?". Instead of asking "How should the Day be presented in a UTC timestamp", you are asking "Should it be presented".
    – rolfl
    Jan 27, 2015 at 22:37
0

Based on your question being centered around the MSE proposal:

I would say the answer would be no!

I don't think it'd be helpful at all due to users reading LTR would see the day and time and totally stop reading and miss the Z realizing it was a UTC date/time.

I would instead suggest that it would be helpful in the context where you actually provide the user a tooltip that displays the Day, Date, and Time as it pertains to their UTC offset (if any), or their current culture.

This answer from Matt Johnson seems to be a step in the right direction.

1
  • The MSE proposal is to include the day so that the mental or manual process of calculating the day is unnecessary. Your answer here claims that mentally having to calculate the day is a better user experience than having the system provide it for you. That cannot be the right UX answer. Your suggestion that the date should be presented with the Day Date and Time in the viewer's timezone is an interesting one, but is not related to this UX question here. Also, see: Why UTC dates?
    – rolfl
    Jan 27, 2015 at 21:51
0

I think a solution is.

Don’t change the hover text. But add the day in local time to the “asked 2 days ago” texted. So show “asked 2 days ago (Web)” or “asked Mon Mar 6 '13 at 12:24” I don’t need to know if day if it is less than 24 yours ago, or yesterday.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.