Is it good practice to include a timezone on a timestamp?

Question

We have an application that displays timestamps for things that have already happened - creation, last edit, activity history.

We have a customer where the source for these events (a user triggering an action) may be in a different timezone, and they've asked us to append timezone information to the display. The majority of our other customers work in one timezone.

The times are always displayed in device-local time, so there would be no logic changes but rather simply the addition of the devices current timezone appended to the end of the timestamp on screen.

Is it good practice to do this, or is there a better way to convey this information?

Answer 1

Specifying the timezone directly in the timestamp is neither good nor bad practice. The answer to your question has more to do with your user experience than any documentation or timestamp formatting.

You stated one or more of your users requested the timezone be added to your timestamps. This would imply your timestamps are currently ambiguous, which is something we want to avoid. You have several different options to remedy this and improve the user experience.

1. Add the timezone to the timestamp (this is clearly the most obvious solution to your problem, which is guaranteed to remove any ambiguity currently present)
2. Clearly state somewhere (the "right" somewhere being the tricky part) that all timestamps are in _______ timezone.
3. Piggybacking on #1, allow this as a user preference. For users in your primary timezone, it can be disabled by default to save a bit of room in your app, but for people outside the "normal" timezone, they can enable this feature.
4. Use relative timestamps instead of absolute timestamps as they're timezone agnostic.

From professional experience, any of the 4 options above (including mixing and matching more than 1) could be extremely beneficial to your users. You'll ultimately have to weight the dev time required to make the change, but the one option I'd say you definitely shouldn't go with is doing nothing.

Answer 2

It depends on the other timestamps you display on your site/app. However, timestamps are almost always used to compare events relatively in a single timeline, so in almost always, it's better to stick to one timezone.

• Give the user an option to select their timestamp. Always load the user-selected time zone, and convert all timestamps to that timestamp.

• For recent events, consider using a "time ago" display. For a example, see this answers timestamp. It does not show the exact timestamp when I posted this answer; it shows how many minutes/hours ago I did it, and you can process this information quickly regardless of the timezone you are in.

• If you are showing "time ago" markers, make it possible to get the exact timestamp as well.

• For filters, you can add relative time filters as well. See this for an example:

Answer 3

Everyone has already answered your question, so I'm not going to go there :)

My comment is more a suggestion.

Please avoid ethereal time stamps like: "Today", "Yesterday", "10 minutes ago", "A week ago". We don't want to think how long was "10 minutes ago" from the time we're reading the content; let alone "A week ago".

I suggest to always use the date and the time. Just look at SE's time stamps: perfect.

The date will need to be formatted according to the region/country it's being displayed at:

• In the US we use Month/Day/Year.
• In Latin America they use Day/Month/Year.
• In Philippines they use both Month/Day/Year and Day/Month/Year.
• In China they use Year/Month/Day (which to me makes the most sense of all).

See all the regions here:

Date format by country

https://en.wikipedia.org/wiki/Date_format_by_country

Answer 4

I can think of 2 other options

1.To display time in international format (if thats not so currently)

hh:mm:ss

2. Additionally we can add the timezone like

   IST 17:09:27

This should remove any confusion for the user, and not take up too much space.

Answer 5

I don't think it would be logical to append since everyone sees their device local time. Instead you may state how long ago the action was performed for easier understanding. An user friendly algorithm can be drawn up. For example, if less than 1 minute, show in seconds, if less than 1 hour show in minutes, etc.

Answer 6

Events happen in a "point in time", stated as numbers.
For example an event that happens at 4PM in London will be seen as happening as 1PM in Buenos Aires. Two different times (numbers) that denote the same point in time.

Now, how you depict it depends on the particular application.

For example if you want to see the events distribution along the hours of the day, like at what time of their day people take breakfast anywhere, then you'd be better off with the local time of each event.
In this case you'd find that people in Buenos Aires take breakfast at about 8AM GMT-3.
People in London already had breakfast maybe at 8AM GMT, that is, at the same local time but three hours earlier.
Same time, different points in time.

On the contrary, if you are dealing with at what time a global audience hits a server, then all timestamps would be better related with the server's location timezone.