Absolute vs. Relative Timestamps: When to Use Which

Information evolves over time like a living organism. What’s relevant this year might not hold as much weight a few years from now. That’s why it’s important to append timestamps to your content. But if you don’t display your timestamps in the right format users could have trouble using them.

Absolute vs. Relative Timestamps

There are two types of timestamps that most sites use. Relative timestamps display the number of minutes, hours, days, weeks or years ago a post was published. Absolute timestamps display the exact date and time a post was published.

Both formats offer utility in different ways. But when should you use one over the other? And how should you display them? These factors will determine whether your timestamps are usable or not.


When to Use Absolute Timestamps

There are times when users need to look back on past content to retrieve information. Without absolute timestamps, users can’t target a specific period to find the information.

Sites that host photos, documents, messages, tasks and events all need absolute timestamps. These content will hold utility in the future when users need to reference them. Use absolute timestamps when users can go back and make use of past content.

Friendly Formatting

The benefit of absolute timestamps over relative ones is that they offer a precise date and time. But dates and times are hard to interpret because not all users live in the same timezone or country. That’s why it’s important to display your absolute timestamps in a friendly format.

Converting Timezones

A problem with absolute timestamps is that they force users to convert timezones to get their local time. This will frustrate those who don’t live in the same timezone as your server. Users should be able to get the right time without making calculations or errors.


Imagine a user who is attending event and doesn’t notice the change in timezone or makes a mistake converting it. The user would end up missing that event, which could lead to unfortunate consequences. In contexts like these, it’s so important that your absolute timestamps are timezone friendly. The way to do this is to optimize your code so that it detects and displays the user’s local timezone instead of the server’s.

Start by storing your timestamps in UTC on your server. UTC is the universal standard that’s not affected by daylight savings time. To display the user’s local time, you need to have the user’s timezone offset, so that you can add it to your database’s UTC value. You can get user’s timezone offset by auto-detecting them with this Javascript Timezone Function.

Converting 24-hour Clock Times

If you have users around the world, not all them will use the same type of clock. Don’t force them to convert times to the clock they use.


Most english-speaking countries use the 12-hour clock as the dominant written and spoken system of time. Other countries use the 12-hour clock in spoken time and 24-hour clock in written notation. But most people in 24-hour countries are so used to both systems that they have no problem switching between the two (source).

Because of this, you should display your times in 12-hour clock as the default. But if you have many users who prefer the 24-hour clock, you could display the 24-hour time in a link or icon tooltip that opens on mouse hover.

Reading Numeric Date Formats

Time formats aren’t the only issue users face when reading an absolute timestamp. Dates can also give users trouble if they’re displayed in a numeric format.


Different countries interpret numeric dates in a different order. Some put the day number first, some put the month number first and some put the year first. Figuring it out is taxing on the cognitive resources, and can lead to user error.

Avoid confusing users by using a written date format on your timestamp. Write out the month name in full or abbreviated form, but don’t abbreviate the year. An abbreviated year can cause confusion with the day number. You can display formatted dates for different countries with this Javascript Date Library. 

When Not to Use Absolute Timestamps

You may not have to deal with all these formatting issues if you don’t even need to use an absolute timestamp. Sometimes a relative timestamp is a better fit. 

If your site content updates often, or has a lot of user activity, you should use relative timestamps. Sites that publish news, or have forums where users post links and comments need to show immediacy. This allows users to stay up-to-date with new information as it comes in.

When to Use Relative Timestamps

Accuracy isn’t important with relative timestamps, but immediacy is. When users want to know how long ago a site published a post, they prefer time units in written form. This way they don’t have to mentally calculate dates and times and count back from the present day.

Not only that, but users don’t have to convert time zones with relative timestamps. Content published an hour ago or five hours ago makes no difference to users who only need a general sense of recency.

Friendly Formatting

There are a few formatting issues with relative timestamps that you should know. Unlike absolute timestamp issues that deal with interpretation, these deal with mental work.

Adaptive Time Units

The trouble with relative timestamps start when the time unit format doesn’t adapt to duration. Instead, it only displays a small subset of time units.


For example, a site may display relative timestamps in minutes, hours and days. But after days it doesn’t display the time units that follow that. Users can get frustrated trying to calculate number of days in the hundreds.

Your relative timestamp should always adapt to duration and display time units accordingly. After 30 days, it should display months. After 12 months, it should display years.

Precise Time Units

If your site doesn’t display content in order of submission, users won’t be able to tell how far apart they were published. You either need to use absolute timestamps, or include precise time units in your relative timestamps.


Precise time units combine different time units together. Instead of only displaying hours in your relative, you would display hours and the minutes that follow to get a more precise time. This gives users a better sense of the time lapse between posts.

Time Unit Abbreviations

Relative timestamps can sometimes take up more space than you want. If you’re displaying them in a confined area, such as a content card or mobile site, you should use time unit abbreviations.


Use standard abbreviations that users can recognize. For the plural forms, don’t add the letter “s” to an abbreviation, use the same form as the singular (source). Here’s a table of standard abbreviations for every time unit.

Automatic Updating

When first viewing a web page, users get an accurate impression of how old each post is. But a fresh timestamp that reads “2 minutes ago” will no longer hold true the longer the user stays on that page.

This is because most relative timestamps don’t automatically update. Users have to refresh their page to get accurate timestamps. If you want to give users accurate relative timestamps, use this jQuery Plugin for automatic updating.

When Not to Use Relative Timestamps

There are times when relative timestamps aren’t as effective as absolute timestamps. When users need to reference a post, it’s easy to do with absolute timestamps because they display unique times. Posts with relative timestamps are harder to reference because they can display the same times.

Another disadvantage with relative timestamps is that they make time proximity harder to measure. Users won’t be able to view how much time has passed between different post submissions. This is important in messaging contexts such as chat, email and discussions.

When to Combine Relative and Absolute Timestamps

Each type of timestamp has their benefits. You can get the benefits of both by combining them together. If your site updates often and hosts past archives for referencing, you may want to combine timestamps.

Friendly Formatting

The challenge with combining both timestamps is finding the right time to convert them and handling the space it takes up.

Inline Display

One way of combining them is to display them inline with each other. You can display the absolute timestamp first and put the relative timestamp in parentheses.


Absolute timestamps include a date and time. Displaying both inline with a relative timestamp can take up a lot of space. You can save space by showing what’s relevant in the moment and leaving out what’s implicit.

To save space, display the time first, but exclude it after 24 hours and replace it with the date. To save even more space, exclude the year and display the full date after the current year passes.

Automatic Conversion

Another way is to convert relative timestamps to absolute ones over time. You can do this by setting the absolute timestamp to display over the relative one when the age of a post passes a certain period.


For example, when a post is older than 4 weeks, it’ll display the published date and time. This allows for a graceful self-archiving of content, which is useful for large sites. Choose a time to convert to absolute timestamps when the pageviews of new content starts to taper off.

Tooltip Timestamps

If you want to display both, but need to conserve space, use tooltip timestamps. When the user hovers their mouse over the relative timestamp, the absolute one will display in the tooltip.


Users won’t know they can view the absolute timestamp on mouse hover if you don’t give them a visual cue. You could use a dotted underline on the timestamp to make it clear. Or you could place a clock icon next to the timestamp that displays the tooltip when they hover over it.

Final Thoughts

Time is a universal concept that transcends cultural barriers. Every user understands time, but not every user will understand your timestamp if it’s not formatted in a friendly way.

The practices and techniques in this article should help you find that friendly format. It’s time to treat timestamps more than just a stamp. They’re an ever-evolving mark of relevancy.



elegant wordpress themes

This Post Has 17 Comments

  1. Staffan Eketorp Reply

    Actually, most countries do not use 12h clocks in written contexts. Which thus leads to you making an imo erronous conclusion about defaults. The most common in the world is to use 12h clocks in spoken language, and 24h clocks in written, which also happens to be the ISO standard.


    • anthony Reply

      The conclusion about defaults was not erroneous because users who use 24h in written often convert the time in 12h for spoken. Because they’re so used to both, they have no problem switching between 12h and 24h.

      Whereas, users who are used to 12h time will have more trouble converting to 24h time because they don’t use 24h time for spoken or written. See the the source link for this in the article.

      • Mike Wallace Reply

        I have to agree with Staffan, as a user who lives in Canada we use both and understand both. The question here isn’t about verbal, written or being able to convert from one to the other (adding 12 to a number is pretty easy…) it’s about context.
        Very often there’s not enough context on a site to know what the values mean.
        If the website says that they offer live support from 9 to 11, when is support available?
        9 to 23?
        9 to 11?
        21 to 23?
        Best practice is 24 hour display.

  2. Daniel Rose Reply

    When displaying a date, please always show the full date, i.e. including the year.

    If all I see is “Jun 21” (like in the post, although it helps that the relative time is also shown), I have to figure out if it means June 21 this year, or from some other year. I’ve seen both variants in the wild, so make it unambiguous.

  3. Nej Kutcharian Reply

    Great article, but in the section which you describe the use of tooltips you should remove the PM after 16:00 in “16:00 PM”. When writing time in 24h format, you don’t need the AM/PM.

  4. James Canfield Reply

    Another reason to use relative timestamps, is that a lot of people do not know today’s date without looking at their phone or calendar. So in some contexts, words like Today, Yesterday are more meaningful than 05/22/15 (I just had to look that up).

  5. Steven Hoober Reply

    Amazingly comprehensive, and useful, but could use another edit pass to make sure it’s organized so everyone can get the proper info out of it. I can see people (say, a dev crunched for time) skimming for the answer to their problem and finding (say) “When Not to Use Relative Timestamps” then doing that, instead of combining the two as you discuss later, and which is more often in my experience the right answer.

    When I say comprehensive, I mean that I covered this as my primary example in this chapter but didn’t spend remotely the time you did on it. Thanks! Good resource.

  6. Isuru Reply

    A very useful article. Relates to an issue I see on Instagram. I have no idea why they display the times which the photos were posted in relative form. I get like this photo was posted 43 weeks ago. Hell, I don’t wanna calculate and get the exact month this was posted!

  7. James Ducker Reply

    Does a language representation of a date not create a language barrier? I.e. 12 syyskuu 2015 is not meaningful unless you happen to speak Finnish, whereas the images on a Finnish photo-sharing website do not otherwise require you to speak Finnish to see their content.

    According to Wikipedia, no locale naturally uses YYYY-DD-MM ordered dates, and so representing dates as YYYY-MM-DD is both language-neutral and unambiguous. At the very least, the ISO-compliant date representation should be available as a tooltip on the language-specific date.

  8. John W Reply

    This is the most useful and comprehensive discussion I have found on this subject so far. Rather than nitpick about 12hr vs 24hr (there’s no pleasing some people) I’ll just say nice work Anthony, it really helped me.

  9. Tippy Reply

    Great article!

    Above under Adaptive time units you state “After 30 days, it should display months. After 12 months, it should display years.”

    Is this best practices? If so do you have a source?

  10. Dick Blitz Reply

    1735 days ago is worthless as is its abbreviated form of 5 years ago. While the latter is somewhat helpful, it is not specific. When in doubt, be specific. IOW, relative use needs to be converted for anything older than a month ago. IOW, 1735 days ago should be a date stamp, i.e. Tuesday, June 25, 2013. Anything under your control that is for private or internal usage, I advise using ultra-specific UTC date/timestamps. It might save your ass one day.

  11. Bak Yeon O Reply

    Please just use ISO 8601 standard.

  12. Rohan Reply

    Relative dates is not a good idea from a programming perspective, as the database will need constant updating. Just store the time using regular old UNIX time in the database (with at least 64-bit values!), serve it up in HTML in ISO 8601 format, and provide some optional client-side Javascript to provide relative dates if your users want that.

  13. adam Reply

    Hi , interesting conversation

    so in the use case of someone checking received calls on their phone when would would make sense to swap from relative to absolute . IE iOS changes from : hh:mm – yesterday – day 5 (ie wednesday) – day 4 – day 3 – day 2- day 1- then absolute ->dd/mm/yyyy

    I am really curious to undertsand the logic behind such choice ? I would assume after 7 days instead of 5 .

    Any thoughts ?

Leave a Reply

Your email address will not be published. Required fields are marked *