Display user's timezone in issues?

We're a global company, and it would be useful for our support teams to be able to see at a glance what time zone the reporter of an issue resides in.

What would be the easiest way for us to display user time zone on an issue?

--

My original question wasn't quite clear. I want to persistently display a timezone on an issue, so that we can tell whether the people affected by the issue are in or out of their local business hours.

7 answers

This widget could not be displayed.

If you mouse-over any user's name in JIRA's issue view (be it Reporter or Assignee or Comment, etc) then you'll see the timezone-related information for that user. Specifically, their current local time and their location.

So, I go look at an issue and see that my own info is reporting...

4:20 PM - Wednesday - London

...and the current assignee says:

8:20 AM - Wednesday - Los Angeles

Does that help at all?

Mark,

Is there a way for the administrator to set a users timezone? It looks like it is dependent on the user setting this in their profile -> user preferences. All users I setup get the default timezone that the JIRA instance "lives" in. Don't mean to hijack the thread...just reading through the morning questions and was curious as I can't see a way to do this using JIRA 5.0.4...

Cheers

Andrew

My first thought was to wonder whether JIRA Command Line Interface (CLI) could help with this. The documentation states that it can update user email and Fullname. I would guess that it could be capable of updating timezone property for a user... why not log a feature request in the CLI Issue Tracker?

Hi, Mark:

Thanks for the information, and it looks like you may have helped some other folks with it.

What I want to do is persistently display the originating time zone of an issue, so that our support staff can tell whether the people affected by the issue are in or out of normal business hours on the reporting end. This is because issues that are affecting people during local business hours get priority.

Does this make sense?

This widget could not be displayed.

I have logged two feature requests that might help with aspects of this issue...

Managing User's Timezone: Logged against JIRA CLI (free)

Querying Issues based on User's Timezone: Logged against JIRA Tricks (commercial plugin)

Neither of these help with the *display* of timezone in the Issue Navigator but I think that, if implemented, would be a great start.

As for what functionality might be expected within JIRA itself, I came across this issue:

Alternative JIRA Views

..that has the (Atlassian) comment:

Things like 'export to Excel', advanced search and timezones I can't see making it into a version anytime soon.

This widget could not be displayed.

The feature request that I logged against JIRA Tricks has now been implemented in v4.0, released on 20th October.

The function usersInTimezone takes a timezone parameter, which is the TZ name as given at http://en.wikipedia.org/wiki/List_of_zoneinfo_time_zones, and returns all users in that timezone.

For example:

reporter in usersInTimezone("America/New_York")

Does this help?

This widget could not be displayed.

Hi there,

why don't you create a new "Custom Field" for your issues, like "Timezone" or "Location", so reporters can fill it out and your support will know if the created issue gets a higher priority or not.

Regards,

Wilhelm

Wilhelm: because that solution would place undue burden on the user, would be massively inefficient, and would be a pain to maintain.

JIRA clearly retains user time-zone information somewhere. The question is how we can programmatically retrieve and display it on issues.

I understand why one would want to automatically query a reporter's timezone and assume it to be the relevant time zone when 'generating' a ticket.

I also appreciate that one can set their timezone preference in user settings and mouse-over the time field to receive clarification.

However, the fact remains there is still ambiguity within our company for those 'reading' a ticket. Employees either (1) aren't aware of the ability to augment the default timezone (and we have to remind current employees or inform all new employees) or (2) are still unclear about due dates being rendered once a ticket has been created. There is invariably the question of 'uh, in which timezone was this intended to be created?' Some people are simply not technically inclined enough to check their preferences or don't immediately think 'maybe I should mouse-over this field to see the timezone.'

If Atlassian provides the ability to mouse-over a field to clarify the timezone, then it is implied that sometimes people still need clarification (otherwise why was that feature developed in the first place). Given that the mouse-over is indeed valuable, why not allow us to specify a time format string (something accepted by strftime) to be associated with a field that can be used for display purposes?

This would *greatly* assist in clearing up ambiguities - which is of utmost importance to global businesses and customers where errors of interpretation literally amount to revenue lost or gained.

We appreciate the automatic timezone translation features you have developed, and we commend you for providing us with mouse-over, but what we really need is a visible label to clear things up.

Just as we add AM and PM to a time to allow us to easily translate between military and standard time, we would appreciate PST and CET to easily, visually identify the proper time zone (without the need for mouse-over).

Thank you, Atlassian, in advance for considering developing a label to satisfy our business needs.

This widget could not be displayed.

Hi Ashton,

I understand why one would want to automatically query a reporter's timezone and assume it to be the relevant time zone when 'generating' a ticket.

I also appreciate that one is able to set their timezone preference in a user's settings as well as mouse-over the time field to receive clarification.

However, the fact remains there is still ambiguity within our company for those 'reading' a ticket. Employees either (1) aren't aware of the ability to augment the default timezone (and we have to remind current employees or inform all new employees) or (2) are still unclear about due dates being rendered once a ticket has been created. There is invariably the question of 'uh, in which timezone was this intended to be created?' Some people are simply not technically inclined enough to check their preferences or don't immediately think 'maybe I should mouse-over this field to see the timezone.'

If you provide the ability to mouse-over a field to clarify the timezone, then it is implied that sometimes people still need clarification (otherwise why was that feature developed in the first place). Given that the mouse-over is indeed valuable, why not allow us to specify a time format string (something accepted by strftime) to be associated with a field that can be used for display purposes?

This would *greatly* assist in clearing up ambiguities - which is of utmost importance to global businesses and customers where errors of interpretation literally amount to revenue lost or gained.

We appreciate the automatic timezone translation features you have developed, and we commend you for providing us with mouse-over, but what we really need is a visible label to clear things up.

Just as we add AM and PM to a time to allow us to easily translate between military and standard time, we would appreciate PST and CET to easily, visually identify the proper time zone (without the need for mouse-over).

Thank you in advance for considering developing a label to satisfy our business needs.

Regards,

Troy Battey

This widget could not be displayed.

I understand why one would want to automatically query a reporter's timezone and assume it to be the relevant time zone when 'generating' a ticket.

I also appreciate that one can set their timezone preference in user settings and mouse-over the time field to receive clarification.

However, the fact remains there is still ambiguity within our company for those 'reading' a ticket. Employees either (1) aren't aware of the ability to augment the default timezone (and we have to remind current employees or inform all new employees) or (2) are still unclear about due dates being rendered once a ticket has been created. There is invariably the question of 'uh, in which timezone was this intended to be created?' Some people are simply not technically inclined enough to check their preferences or don't immediately think 'maybe I should mouse-over this field to see the timezone.'

If Atlassian provides the ability to mouse-over a field to clarify the timezone, then it is implied that sometimes people still need clarification (otherwise why was that feature developed in the first place). Given that the mouse-over is indeed valuable, why not allow us to specify a time format string (something accepted by strftime) to be associated with a field that can be used for display purposes?

This would *greatly* assist in clearing up ambiguities - which is of utmost importance to global businesses and customers where errors of interpretation literally amount to revenue lost/gained.

We appreciate the automatic timezone translation features Atlassian has developed, and we commend Atlassian for providing us with mouse-over, but what we really need is a visible label to clear things up.

Just as we add AM and PM to a time to allow us to easily translate between military and standard time, we would appreciate PST and CET to easily, visually identify the proper time zone (without the need for mouse-over).

Thank you, Atlassian, in advance for considering developing a label to satisfy our business needs.

Instead of using the 12 hour clock and adding AM/PM it would be a lot more helpful to use that space to display an explicit timezone code.

This widget could not be displayed.

I don't have an answer, I just want to "plus 1" and also show the assignee time zone. There are a lot of hard feelings over an assignee not responding soon enough because the reporter doesn't realize he's dealing with someone on the other side of the world.

Since Jira has us so locked down in our license choices and permissions schemes, the only way we can drive people to Service Desk to create a ticket is to lock them them into Service Desk view only. In that view, they can't even SEE the assignee, much less hover over their name to see a time zone.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

285 views 5 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you