teste

aaa

Far as I can tell, this hasn't been fixed at all. All times are the system time still.

I've opened JRA-28939 to track the request for time zone support in emails.

@luis There are potentially the Created date, Updated date, Due Date and all custom Date Picker and Date Time fields.
With 4.4 and customized email templates I had to do something like this:

#set ($startTime = $customFieldManager.getCustomFieldObject("customfield_10425").getValue($issue))
Same timezone as JIRA system: $startTime 
Formatted in the timezone of the user the email is being sent to: $dateformatter.formatDMYHMS($startTime))

So I think there is likely still a wrinkle in email templates.

gbrauer1, I believe most JIRA emails do not contain the time in the email body. For emails that do contain the time, I would expect it to respect the user's time zone setting.

Is my understanding correct that time zone support has only been implemented in the web UI, but there is no time zone support yet for outgoing emails?

azhdanov, the easiest way to format/parse dates in a timezone-aware manner is to use a DateTimeFormatter. See the API documentation for the package com.atlassian.jira.datetime.

The TimeZoneManager and TimeZoneService also provide some more low-level functionality, if the above classes isn't enough for your use (see com.atlassian.jira.timezone).

Could someone please bring the light on how it is implemented? Specifically, how to get user's time-zone in Gadget and Report?

Answered myself: see TimeZoneManager

epic! time to upgrade to 4.4.

Atlassian should organize a big party for resolving JRA-9.

OMG! For real? Finally. I could not be happier that this ticket is finally done...I voted on this one I don't know how long ago and it is finally here. Thank you Atlassians!

Nice, that this one got resolved, finally! Now it will take just some additional years to release JIRA 4.4
Seriously, is there a schedule for this release?

Achievement unlocked: Resolve a nine year old ticket. ;)

Just in time for the Summit keynote this morning!

when is 4.4 release and approximately by when should this be available on JIRA Studio?

@Marcel

Thanks for passing on those comments.
We are aware of JRA-10613 and if we have time we may put this into the 4.4 release.
At this stage we have not started investigations into JRA-10613 as we are still working on user time zone stories.

Cheers,
Roy

we have a world wide company that use jira. Our users log time in the US but it shows up as the time in New Zealand. I look forward to this fix!!!

Ian Wells
Trimble New Zealand

_Armen Badal wrote:_

[...] we need 2 features [...] b) time / date entry format [...] 2) Displaying times and dates: time and dates presented in the time zone and preferred format of the user [...]

Please vote for JRA-10613. It's missing for me too (still I don't testet the EAP yet, but of what I'd seen in the Announcments, this isn't fixed in the next release!

@Ivar,

JIRA 4.4 is not out yet.

You may be referring to the 4.4 EAP versions which we release to get feedback from customers such as yourself, so if you have any time zone feedback please let us know.

Cheers,
Roy

So - is it time to set the Fix version now? 4.4 is out...?

Sergiy,

JIRA 4.4 is the target release. However we do not set the Fix Version until we are 100% confident that we will be shipping with it.
Right now time zone support is still in it's early testing phase, which we would love your feedback on.

Cheers,
Roy

Will it be included in 4.4 or it's still at stage of prototyping?
Why I am asking - Fix Version/s is still None

Mike came good on his word:
http://confluence.atlassian.com/display/JIRA/JIRA+4.4+EAP+3+Release+Notes#JIRA4.4EAP3ReleaseNotes-UserTimeZones%28newinEAP3%29

Filed over 9 years ago? Wow! I wonder if it was addressed back in 2002 if the estimate would've been lower than 600hrs... Good luck guys

Sounds like will be implemented in 4.4.

Now that's what I call optimism!

We are still working on timezone support but unfortunately it will not make it into 4.3.

Sounds like will be implemented in 4.4.

@Stuart.

We are still working on timezone support but unfortunately it will not make it into 4.3.

It was stated at the Summit 2010 that it would be fixed "soon". I'd say 8 months is "soon". Any updates yet?

I will reiterate a couple of comments, this really should be part of the core functionality, not requiring a plugin. What is the ETA for this? Since we are using this in an enterprise environment, upgrades take time and planning. Our team is unlikely to see this for likely 6 months after you release it. Can you get this into 4.3 so we have a chance at getting it into our installation before the end of 2011?

@David - Very much agreed. We have had to add a time zone field for certain things just so the time listed is very clear (the field does nothing but force the reporter to make sure they have entered the right time in the right timezone...)

Look forward to Atlassian's implementation. Our clients expect this sort of fundamental feature out of the box.

Is there an ETA on a fix for this? We have teams collaborating world wide and we are trying to get them to adopt JIRA. We will test out MyZone plugin, but we would prefer a complete solution that includes all views and doesn't require the user to make changes.

Thanks,
Becket

Have anyone tested the MyZone plug-in in Jira 3.13.4??

T.
Srini

Hi Christina,

Many thanks for your positive feedback and we are glad that you like it!
At this time we are not looking to bundle the plugin because we are still investigating other ways that we can add more robust timezone support into JIRA.

However in a near future release it will be easier to download and install plugins directly from JIRA. In fact you can do this now by installing the Atlassian Universal Plugin Manager.

Cheers,
Roy

Hi all,

we just tested the MyZone Plugin. It is really great. Is it possible to make this a standard plugin for Jira so that it is installed during upgrades?

Christina Edelbluth

Hi Mark,

We recently changed the workflow statuses for this issue type and removed the 'Short Term Roadmap' status.

Time tracking is still on our cards, and may I ask if you have tested the MyZone plugin?
Feel free to email me directly if you prefer.

Cheers,
Roy Krishna
JIRA Product Management
roy at atlassian dot com

Why the move from Short Term Roadmap to Open? Curious, as this was announced that it would be completed very soon back in June...

@Matt Doar - Many thanks!

@Mark, David, Oliver - Thanks for the comments. We are not suggesting that this is a complete solution to this issue, but rather a simple plugin that a developer has created to address the view issue page. It was done in his spare time as he wanted a simple solution to view times on the issue screen. Again, let me confirm with you that this is not the Atlassian supported solution. We will be looking at this down the track. Sorry that I was not more clear on this point earlier.

Please feel free to email me directly on this matter.

Cheers,
Roy Krishna
JIRA Product Management
roy at atlassian dot com

I agree. I also expect an full blown und full integrated solution.

@David Corley: Exactly! Mike Cannon-Brookes said that Atlassian would be implementing a solution. To suggest that we use this third-party, UNSUPPORTED, plugin is not only NOT a solution, but also irresponsible of Atlassian. Additionally, this plugin does not cover all areas where time is listed, which, to me and my users, again, is not a complete solution.

Please provide an actual update on the real solution that will be built into JIRA and supported by Atlassian.

Roy, I'm presuming Atlassian are still planning on implementing full timezone support next year as per Mike Cannon-Brookes keynote at Summit this year?
In other words, this plugin should only be considered as a short-term solution (and partial) solution to the problem?

Nice looking plugin, glad someone did something about this.

~Matt

Hi Guys,

Just a quick note to let you know that a JIRA developer has created a small plugin named MyZone that has limited timezone support.

The MyZone plugin will give each user the option of setting their timezone location via their user profile. It will then show converted dates and times on the view issue page. In the example screenshot below you can see converted dates and times as underlined while the mouse hover shows the JIRA server time (relative dates e.g.Today 2:30pm are also converted):

Please note that the plugin will not convert times in the issue navigator nor when entering dates/times in issues, it only currently works on the view issue display.

If you are interested in testing MyZone you can download the plugin from the Atlassian Plugin Exchange. Please note that it is not an Atlassian supported plugin but the developer is keen to hear your thoughts and feedback. So we ask that you send all issues and feedback directly to the developer via the plugin site directly. (You will need to sign up for a free account)

Happy testing!

Roy Krishna
JIRA Product Management

@David Bond This was announced at the Summit this summer that it would be fixed in 4.x and soon.

Useful and gets my vote, but the user timezone should come from Crowd so it can also be shown in the Confluence Profile for the user.

I have recently introduced Jira to a company looking to buy. I installed the $10 version and this was their first complaint. I've voted, but have a sinking feeling that my vote is going to count for jack. This is a hygiene issue and has affected a sale. Every other enterprise system in the world has user timezone. You should be embarassed Atlassian.

It's worth noting here that the Activity Stream in Jira 4.x and the Activity Stream gadget (provided by the makers of Jira) both seem to show the times in the client timezone. So now, depending on where you look in Jira, you get different times for the dates - even on the same screen! (the view issue screen showing server timezone with the activity stream showing client timezone at the bottom). This is very confusing, esp. to new users. I'd raise it as a bug, but I fear that would take a step backwards, instead of the original limitation being fixed. So we'll just live with it for now.

Yay!

For what it's worth, there's a video of a talk from the recent Atlassian summit where Mike Cannon-Brookes promised this would be delivered in 2011.

This is a long thread so pardon repetitions; due to the international presence of our multiple sites, operations and users we need 2 features:
1) Entering date and time: time & date format localized to the users work station locale and preferences for a) time / date zone and b) time / date entry format
2) Displaying times and dates: time and dates presented in the time zone and preferred format of the user [based on work station locale and preferences]; as a short term fix [an alternative until this is resolved] display the dates qualified with time zone so the reader can derive the correct times/dates and (when needed) calculate any time/date differences correctly

We have people in the US, AU, FR, IN, all working on the same tasks and I cannot say how much I am disappointed by the fact JIRA does not handle time zones in the user preferences !

We want to implement JIRA for an international team, and lacking time zones causes discomfort for the users who are not in the zone of the server. It is strange, that many efforts were implemented to make JIRA multilanguage but the current issue is neglected in the age of cloud computing and distrubuted teams

We are a team of developers in 4 different sites across the world. We just moved to using JIRA and I was very surprised that a basic thing such as adjusting time zone for localization was not already done for a mature product like JIRA.

Can we have this feature implemented in the next release, please?

Yes, would love to see this - this is almost the first thing we implement on any new project. Frustrating to see all our JIRA dates appearing to be tomorrow (here in Western Canada). And it gets even worse when trying to understand reports. At least if the date pickers mentioned that they were in UTC, our users might not go readjusting them to the wrong date and time. So as many posters have mentioned, it is easy to get the timezone from the browser or from a profile and use that to display any dates, and this would be a desperately welcomed feature.

This issue is extremely annoying. But the fact that it has not been addressed for so long is pathetic!

We have users in US (2 timezones) and EU (3 timezones). Our Jira is hosted in the US. How should we decide what timezone to display? BTW I see this issue is EIGHT YEARS OLD. Come on!

This issue is causing problems to us as well, having hundreds of users distributed in 7 timezones.

I have about 1k users interested in this.
I see Atlassian slowly becoming Microsoft. Products becoming larger but without useful functionality that everyone wants. That's the power of opensource - needed functionality is implemented. But I do not see any reason to migrate to JIRA 4.0 or Confluence 3.1.

I vote; Let us have local TimeZone NOW please. I have over 5,000 interested in this Enhancement

I'm already 305th on the Vote. Let us have local TimeZone NOW please.

How many votes do we need to get this implemented sooner? I can get around 400 from my company.

he he I'm the 300th vote ! I guess everything has been already said. We need it, please ...

Long Term Roadmap status, no assignee, priority MINOR. An 8-year old issue with 299 votes must have pririty MAJOR or higher, and an assignee.

Long Term Roadmap status with no assignee - sounds like long and
carefree life.

Happy birthday JRA-9. You are 8 years old today!

Like many people above we use Jira in an international context, with most users being in either IST or CET (India or Western Europe). Having all the times displayed in EST (the server is in the US) is really inconvenient and confusing everybody. Worse still, that machine will probably move soon to an other time zone, changing the offset...

I've worked with Jira for a long time and I love the product, but this issue is very vexing. No handling of time zones in a web collaborative software in 2010? It's a bit hard to explain to people.

+1 from me.
We have a very complicated (on par with JIRA) piece of software that we've devloped. It covers about 15 timezones, and we managed to fix the timezone issue for users. We just have a 'timezone' dropdown list at the top right of the screen after a user logs in. They can dynamically select the timezone, then everything they see is displayed in their selected timezone. Schedules, etc are saved with timezone information stored (ie. it knows what timezone the user was in when they created a schedule).
It's not trivial, but it's certainly not a massive task.

A Greasemonkey script that corrects timestamps for users in a different timezone might be a quickest workaround. Does anybody have such a thing?

+1 vote. We have been huge fans of Jira, but have just opened a site in another timezone and have realised that Jira has absolutely no support for that at all. None. Zip.

That must be embarrassing.

Its a "minor" issue, apparently.

We are in the same boat. We have an international team (which, by the way, we pay quite a bit for in terms of JIRA licensing), and the time zone math is just a headache. We all want to see times displayed in our own time zone, not someone else's.

I'm not surprised it has been moved to long term when I see Priority "minor" and time estimate 600 hours.
But is it really minor and so long to do?

Long term?!

Bad choice....

This is such a needed feature.

Let me be the first of many, no doubt, to express disappointment that this issue has moved from the short term to the long term road map. Though this is a minor feature, it's like a spelling mistake on a menu. You can't believe it hasn't been noticed and fixed. Every day it eats away a little bit at your satisfaction with the product. JIRA has lots of great features and it does a lot for us, but when this does get fixed I won't be saying "what a cool feature". I'll be saying "I can't believe how long it took for them to get around to this."

Thanks for the opportunity to comment and for the courage to put your product planning out in public.

"RT @joshleejosh:JIRA has like eleven million features and config options, but displaying times in your local time zone isn't one of them."

Just saw this on twitter.

I have teams in 2 time zones and would very much like this functionality as well.

Voted & watching. We're in the same boat, and to be honest - I can't believe JIRA doesn't already support this.

Just adding another "me too". We're using Jira to coordinate work between our offices in Atlanta and in Paris, and this is going to make things pretty confusing for one of the two teams.

Me too, on behalf of iTKO. Server in Dallas USA, I work in Melbourne Australia and we have a team scattered all over the world. I can't be bothered doing the mental arithmetic that isn't necessary with all the other servers hosted in Dallas, including our Confluence instance. I know you need to run on a bunch of databases so store the dates as seconds since epoch GMT and do the conversion on the fly for the user's nominated timzeone. It sucks to store dates that way in the db, I know, but it's either that or restrict the databases or continue to have people pointing at you and shaking their heads .

Some tasks can take a lot of time, in particular if you are working on such fundamentals as working with time. Nevertheless this is an important feature for distributed teams.

Hi Stafford Vaughan!

Yes, it is right: Jira is not a simple bulletin board. But that makes it even worse that such an important feature is not implemented for years. And estimated time 600h: that is 75 days assumed a developer works 8 hours per day. Wow! I should give an estimation for a feature as basic as this to my manager, he would ask me about the quality of my projects Java code.

Do not get me wrong, I might not grasp the complexity of the task. I only want to tell you: we need that feature very urgently.

m27315 - JIRA isn't a simple bulletin board. It's use of times and dates are much more complicated, hence the long timeframe to get this improvement implemented. I'm sure it will be done at some stage, it's just a matter of balancing this request with the other few thousand.

Even the simplest bulletin boards and forums support this feature. Jira should have had this years ago.
+1, should have been "fixed" yesterday.

I'd like to add a me too for this – I can do the mental arithmatic on our Jira hosted, to work out when things were done, but it would be so nice for the dates to be localised to me.

Please please please do this.

Kind of sad and disappointing to see that this is/was ever an issue to begin with. My vote is in.
[this comment added 12:50AM EST]

Also a problem for us. We're being asked to use a new global roll out & yet everyone in diff countries has to work around UTC time, rather clumsy & error prone!

Consider AT&T on the list of companies that consider this a high priority, not sure how we missed it during our initial evaluation but now that we're well into JIRA (2+ years) and loving it, this has become a bigger and bigger issue that I can't seem to keep explaining my way out of to the groups that we've managed to move into JIRA from other ticketing systems.

How is this working (or not) with the new JIRA hosted model? Thats got to affect those groups?

Wow... what an embarrassment

Ran across this issue as we're moving over to use JIRA as an agile tool tracker (using the GreenHopper plugin) and suddenly timestamps/work logs take on a whole new importance. I thought Atlassians motto was DFTC? Maybe this issue was logged before that came about?

As a technical suggestion, grab the timezone from javascript and do the conversions in the UI, keep the database on a standard timezone – that's what I've done to handle this problem before. You can get tricky and allow a user profile override too but that has problems if people jump between timezones. At least as a first step so you dont have to go crazy figuring out how to support N database timestamp schemes.

+1 from Jira Enterprise customer (if that helps get it short_er listed)

Just adding my voice to this, we work in multiple continents / timezones and use Jira for our change control system. It is a hinderance for our users to have to do timezone conversions in order to properly schedule change controls. It would be a huge help if you could move this up in the schedule.

This is also a problem for us. We host Jira in the USA but work in Europe so you can imagine that some logs result with different date (as for some cases it is still previous day in the States)

this new feature + with enchancement on Timetracking to setup Holidays event will be very usefull

Just looked at issue number.
Number #9
Very first unresolved issue from JIRA salad days.
184 votes & still minor priority!

I personally read through all comments on all JIRA project related issues - so your comments are not going ignored.

This issue is one of the top voted for issues as well as being the oldest.

I have this issue short listed for a 4.x release, we will continue to balance top requested / small improvements with each major release.

I wish I could be more specific, but at this time I am unable to provide more details.

When I have more concrete information regarding when this issue will be addressed, I will jump in here and provide those details.

Regards,

Brian Lane
JIRA Product Manager

This is a critical issue for us. We have support resources in three geographic locations (US, GB, SG) and customers worldwide. It would help us greatly if this functionality became standard

Could somebody from Atlassian kindly comment on this issue, the last we heard from your team is a year ago.
Thanks,
Ganesh

We (Sandisk) vote for it too!!!

ISS Art Ltd. votes for it

This is a big one for us too.

Hope it gets resolved soon as we are now dealing with multiple clients in different countries.

How has this not been fixed yet? I'm surpised Atlassian has been spending their time these past few years on all sorts of value-add features, while ignoring fixing value-detract deficiencies like this. Very disappointing.

This is in no way a minor bug. Without accurate/intuitive time stamps, it is very difficult to collaborate internationally, and just causes confusion. Is there any reason this keeps getting put off? As it is already implemented in Confluence, I'd think it wouldn't take that many man hours to complete, and it would make a huge difference for a lot of users.

Well, it is JRA-9. Meaning, the ninth bug ever filed against JIRA ...

At first I thought this was started in February of 07, but it's been around since February of 02 !!! What are the chances of this geting done.

C'mon guys, it's never too late. lol...

We're running JIRA on the US East Coast and just set up a project for our Ireland dev team. They are already unhappy with the time zone issue. I can't set up a new instance for them, because they are working on the same product.

Please consider knocking this one out.

This is a significant issue. I was surprised to find that this wasn't yet implemented. This is basic internationalization support in these days of wide spread globalization. And this is trivial to do with the great internationalization and localization libraries provided by Java.

I know you use the voting system, and there is a lot of power in it, but right now I think Atlassian needs to bite the bullet and just clean up a lot of issues which fall into the hygiene category.

As I am really pushing JIRA, in ways I have never before, I am finding again and again issues which just shouldn't be there. And then I have to explain my choice of JIRA and why the limitations aren't that important.

The fact is, that many of these hygiene issues may not be getting the votes they need, because when folks are in the evaluation process and encounter them, they just walk away.

So, this older gentleman is cleaning out his closet and comes across a claim ticket for shoes that were sent for repair over 25 years earlier. He remembers that the store is still in business, so just for fun, he goes to the store, and shows them the claim ticket. "I don't suppose you still have my shoes, after 25 years", he joked. "Yes", answered the proprietor. "They'll be ready next Tuesday".

Wow,
once I saw a picture in a magazine:
a guy in waiter dress is sitting in the chair reading a magazine,
and a taperecorder was standing nearby, shouting in all different fonts,
waiter! waiter! WAITER! waiTER! WAIter!
somebody asked him:
"hey, Bob, what on Earth you're doing?"
the answer was:
"I am preparing for a new job here!"

We are implementing globally and need different timezones for each office. We created a separate project for each office. Ideally, it will adjust for the timezone of each user but setting a timezone by project would also be acceptable for us.

We have the same problems mentioned above. We have offices in California and Korea with multiple users collaborating on projects with deadlines that involve users in both places.

In Korea if issues are logged to be completed by April 1st 9am, that would be Mar 31st 5pm here in California.

Clearly, this could be problematic if a deadline is misinterpreted.

In any event, I'm voting for this issue to be fixed and hopefully included in a release sooner rather than later if at all possible.

Thanks,

Adam G. Saint-Prix [Outspark]

I am displaying the current server time in the footer. This makes it easier for users to at least quickly judge how old a comment is.

Just edit $JIRAHOME\includes\decorators\footer.jsp

old:

...
<div class="footer">
...

new:

...
<div class="footer">
Current Server Time: <%= new java.util.Date() %> <br/>
...

If someone who knows JSP can tell me how to format the date above into "dd/MMM/yyyy hh:mm a z" format it would be appreciated.

This is also important for us. We have offices in UK, Europe, across North America and Australia and each time zone has to try and convert back to GMT (where the server is based) - it makes thing very difficult.

I also think this is actually kind of a bug.

In my opinion fixing this kind of thing is more important than adding, say, AJAX lookups of usernames and issues.

Yes, this is also a critical feature for our company, with offices and clients spread around the world. With the newly added/improved work log functionality (good work by the way!) it becomes even more important.

Jed,

It means you can loose your data consistency only by switching your JIRA installation from a server to another. So it makes crystal clear that you cannot rely on the database to manange timezones and raises this issue criticity.
The best would be to store all the dates GMT and then to change the timzone only when the date is displayed according to the user settings, Java can handle this easily.

Cheers,

Jean-Baptiste

Hi,

The FAQ for the way issues are scheduled can be found here:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

We are listening, and with every release we try to enhance JIRA as much as we can. Some of the popular requested features included in the last few releases are:

• editable comments
• convert issues to sub tasks and vice versa
• added start dates and the ability to edit and delete worklogs
• aggregate time tracking information across sub tasks

We would prefer to leave this issue open as we are planning to look at it in the future. However, as I have mentioned in my previous comment, we do not have the date for its implementation.

Cheers,
Anton

It depends on the database and whether there is timezone information in the date columns. Postgres for example stores the data with a timezone, so if I change my JIRA server timezone from GMT+10 (Sydney) to GMT+0 (London) then the display of the time (say on the issue updated time) will go back 10 hours. So if originally I edited it at 5pm Sun, change my JIRA timezone to London then re-display the issue it will show it was updated at 7am.

MySQL timezone support doesn't seem to store timezone with the date, but as a global preference. This means that the JIRA's server timezone is effectively ignored if changed.

Likewise, this is a critical issue for our organization as well.

I have a question...

What is the impact of changing the timezone on the live system? What happens to the information currently in the MySQL database?

This question is also tracked in https://support.atlassian.com/browse/JSP-16047

What I have now understood is that if you want really want something done in JIRA, there is no other solution than doing it yourself.

Hi Anton,

It would help others if Atlassian provided an FAQ on scheduling issues. The response below is a nice way of saying that the issue will remain unscheduled and that's the way it is. I believe people want to know one way or the other whether an issue will be fixed.

James.

Hi,

Thank you for your comments and feedback. We realise that this issue is important and would like to implement it in the future. We have a lot (thousands) of feature and improvement requests and our main challenge is to select which features to add next.

We woud like to do this feature carefully as users can exist in various time zaones and every time a date is entered (due date, date and date/time custom fields) we need to ensure we do not store the wrong date.

Unfortunately, at the moment this feature is not scheduled for a particular release, and therefore I am unable to provide a date for its implementation. I am sorry for not being able to help more at this time.

Thanks,
Anton

We are also seriously looking at Jira at the moment, and a major blocker for us is the lack of user timezones. We need "follow the sun" support for our support teams and it's critical that the user's local timezones are used.

Has this been scheduled for a future release?

I really think this feature should have a higher priority. Medium, if not High... but definately not Minor.

This is one of those things that seem minor but cause quite a bit of inconvenience from an end-user perspective.

I've just started using JIRA and I am really liking it. I noticed that one of my colleagues had logged an issue at 3:37am, which I am sure she didn't and a bit of digging around revealed that this was a different timezone.

We're using an Enterprise Edition of JIRA with projects running across different continents and this feature is an absolute must in order to help us correctly synchronise and track issues.

I actually think that this is a HIGH priority. Without this feature, the only option is to create a separate Jira system for each time zone, which is not a good solution at all.

I think this really should have been in from the beginning. The main reason is not that it allows people from different timezones to collaborate. For me, the main reason is that I believe a server's timezone should always be set to GMT / UTC to shield it from the wackiness of daylight saving time and switching timezone. In this scenario the pure server time is "unusable" for nearly all JIRA users (relatively few people live in a GMT timezone). For instance, we're on Eastern Time in the U.S., but the JIRA time is always GMT.

So, please fix this soon since it makes tracking down times and dates usable in JIRA for us.

Just want to add my two cents that we'd really like this feature. We are a small company with most employees located in California, but we have employees all over the U.S. We just moved our JIRA server to a data center located out of the timezone. I assumed that I'd be able to configure the timezone since I can do that today in Confluence. I was surprised that I couldn't configure the timezone and was disappointed to see this feature request open for almost 3 1/2 years.

Atlassian, I love you guys. I love JIRA and Confluence, but I find myself frustrated at the differences between JIRA and Conflence. It's very frustrating to see a feature available in one product, but not the other. It leaves a strong impression that you treat the two products almost as if they were run by separate companies. Please, please strive to get more consistency between the two products and please, please implement this feature.

You're right Jeff: how something so simple can not be implemented? Even Confluence support it...

Wow, still open for debate after 3 years? I too work for a company that's got people all over - California, Boston, Belgium, India, ... This is the only tool we use that does not support client-specific timezone adjustment.

I would like to add my support for this new feature. It would certainly be advantageous to our users if they could see times in their local time zone, rather than that of the server.

There is a bit of debate whether this is hard or easy....
Though Confluence guys just managed to put it into 2.3. so I guess we may revisit soon. We don't really consider how long an issue has been open when scheduling, we try to schedule the most important issues at the time.

Sorry I don't have any more info at the moment.

Cheers,
Nick

Is this a big issue to fix since it hasn't been fixed yet?

I work in a large global organisation which has recently adopted JIRA. This timezone fix is essential to us as we are scattered across different timezones and tracking when an issue was logged / updated in our own timezone is critical.

It is very disappointing that a simple feature request is now outstanding for over three years!!! I imagine this was overlooked when this product was evaluated and I for one would have seen this as a potential showstopper to purchasing this.

Is there any ETA for this feature in JIRA? I've had some requests for this recently.

Thanks,
Stafford

Patrick,

All times are currently reported in the servers timezone. We will post when we schedule user specific timezones.

Cheers,
Nick

Hi,

This doesn't seem to have been answered specifically so:

Using Windows XP and IE 6, if I have a TZ environment variable properly set, will JIRA pick that up and report the local time?

Thanks.

This is definitely something we need also.

Yeah this is a key option for users who aren't worldly sensitive to time

We're using Jira across about four offices and some time zones for them are 12 hours away. It makes it very confusing to figure out when a change has been made to a bug. I've added my vote.

1) It does not seem to be possible to configure a timezone anywhere

2) At the very least, the time displays should include the timezone being used

I'd like to see it implemented too. Our users are going crazy with the math

This is very important to us since our users are spread throughout the USA in every timezone. We use date fields to determine the responsiveness (Mean time to respond) to an issue. Not having the local timezone has been causing problems for some users since they get it wrong by up to three hours.

I'd like to see this feature aswell. In a centralized server that is shared internationally, people want to see local times not EST or GMT.

This cannot be inferred from the locale in my opinion. I might live in the US and have a timezone of EST but want to display the German language interface.

You could presumably identify the user's locale from the request too...

This is due to users not having a timezone set, see linked Issue.