|
[
Permalink
| « Hide
]
Owen Fellows added a comment - 16/Nov/03 07:55 PM
This is due to users not having a timezone set, see linked Issue.
You could presumably identify the user's locale from the request too...
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. 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 it implemented too. Our users are going crazy with the math
 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 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.
Yeah this is a key option for users who aren't worldly sensitive to time
This is definitely something we need also.
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. Patrick,
All times are currently reported in the servers timezone. We will post when we schedule user specific timezones. Cheers, Is there any ETA for this feature in JIRA? I've had some requests for this recently.
Thanks, 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. 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, 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.
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.
You're right Jeff: how something so simple can not be implemented? Even Confluence support it...
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. 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. 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 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. 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? 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, 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. 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.
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 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 Hi,
The FAQ for the way issues are scheduled can be found here: 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:
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, 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. Cheers, Jean-Baptiste 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.
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 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: footer.jsp ...
<div class="footer">
...
new: footer.jsp ... <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. 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] 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.
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!" 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".
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. 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. 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... Well, it is JRA-9. Meaning, the ninth bug ever filed against JIRA ...
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.
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 a big one for us too.
Hope it gets resolved soon as we are now dealing with multiple clients in different countries. ISS Art Ltd. votes for it
 We (Sandisk) vote for it too!!!
Could somebody from Atlassian kindly comment on this issue, the last we heard from your team is a year ago.
Thanks, Ganesh 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 Just looked at issue number.
Number #9  Very first unresolved issue from JIRA salad days. 184 votes & still minor priority! this new feature + with enchancement on Timetracking to setup Holidays event will be very usefull
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.
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? 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) 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? 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] 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. 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.
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Short Term Roadmap
Minor
User Preference: User Time Zones
