Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-26265

Date Time custom field doesn't calculate current time

XMLWordPrintable

      The Date Time custom field no longer reporting the current time. It looks as if the time is reporting in UTC +8.

      The field was working correctly in JIRA 4.3.4. Does not work in JIRA versions 4.4+

      Workaround:

      There is a workaround found by lucgauf:
      Modify the file Calendar-min.js located in /includes/lib/calendar/
      This file looks like there is no line break so I can't give the line but you have to include this code between :

      Calendar-min.js
      ...
this.isPopup=false
}
// start code to add
if (this.dateStr) {
       var dateStrCustom = ""+this.dateStr;
       dateStrCustom = dateStrCustom.replace(/-/g,"/").replace(/(\d\d)+T+(\d\d)/, "$1 $2");
        this.date=new Date(dateStrCustom);
}

if (!this.date || isNaN(this.date)) {
        this.date=new Date();
}
// end code to add

var table=Calendar.createElement("table");
...

      It works with IE9 and FF8, our JIRA version is 4.4.3.

      Important: This workaround consists of modifying the bundled JIRA code, and hence, Atlassian does not provide support to it. We recommend to upgrade your JIRA to a version which contains the fix to resolve this issue permanently.

        1. date-time-custom-field-issue.png
          date-time-custom-field-issue.png
          113 kB
        2. jabad_gmt-10.jpg
          jabad_gmt-10.jpg
          66 kB
        3. Screen shot 2011-11-15 at 9.31.16 AM.png
          Screen shot 2011-11-15 at 9.31.16 AM.png
          141 kB

            [JRASERVER-26265] Date Time custom field doesn't calculate current time

            Mark Claydon added a comment -

            Luc, your IT Team is awesome! Thanks! It works perfectly! We use JIRA 4.4.5.

            One note for other folks who may implement this:
            I came across a problem in IE 9 whereby the calendar gadget was not appearing. When I would click on the calendar icon the screen would jump back to the top, but no calendar would appear. I played around with the compatibility settings in IE and that got the calendar to pop up, but honestly, when I put the compatibility settings back to their original settings, the calendar continued to display properly. If you encounter this problem, I suggest going down this route first:
            Administration -> System, Look & Feel.
            Scroll to the bottom of the page where you will see "Refresh Client Resources". Click on that.
            Click on "Clicking this link".

            Mark Claydon added a comment - Luc, your IT Team is awesome! Thanks! It works perfectly! We use JIRA 4.4.5. One note for other folks who may implement this: I came across a problem in IE 9 whereby the calendar gadget was not appearing. When I would click on the calendar icon the screen would jump back to the top, but no calendar would appear. I played around with the compatibility settings in IE and that got the calendar to pop up, but honestly, when I put the compatibility settings back to their original settings, the calendar continued to display properly. If you encounter this problem, I suggest going down this route first: Administration -> System, Look & Feel. Scroll to the bottom of the page where you will see "Refresh Client Resources". Click on that. Click on "Clicking this link".

            luc gaufreteau added a comment - - edited

            Here is the workaround of my IT team.

            You have to modify the file Calendar-min.js located /includes/lib/calendar/

            This file looks like there is no line break so I can't give the line but you have to include this code between :

            Calendar-min.js
            ...
this.isPopup=false
}
// start code to add
if (this.dateStr) {
       var dateStrCustom = ""+this.dateStr;
       dateStrCustom = dateStrCustom.replace(/-/g,"/").replace(/(\d\d)+T+(\d\d)/, "$1 $2");
        this.date=new Date(dateStrCustom);
}

if (!this.date || isNaN(this.date)) {
        this.date=new Date();
}
// end code to add

var table=Calendar.createElement("table");
...

            It works with IE9 and FF8, our JIRA version is 4.4.3.

            luc gaufreteau added a comment - - edited Here is the workaround of my IT team. You have to modify the file Calendar-min.js located /includes/lib/calendar/ This file looks like there is no line break so I can't give the line but you have to include this code between : Calendar-min.js ... this .isPopup= false } // start code to add if ( this .dateStr) { var dateStrCustom = ""+ this .dateStr; dateStrCustom = dateStrCustom.replace(/-/g, "/" ).replace(/(\d\d)+T+(\d\d)/, "$1 $2" ); this .date= new Date(dateStrCustom); } if (! this .date || isNaN( this .date)) { this .date= new Date(); } // end code to add var table=Calendar.createElement( "table" ); ... It works with IE9 and FF8, our JIRA version is 4.4.3.

            Mark Claydon added a comment -

            Has anyone found a workaround for this problem? We can't simply upgrade to JIRA 6.

            Mark Claydon added a comment - Has anyone found a workaround for this problem? We can't simply upgrade to JIRA 6.

            Adhip Pokharel added a comment -

            Thanks for the information. We were going to upgrade JIRA after June 15. We might just wait 10 more days then if the dates for 6.0.3 doesn't change.

            Adhip Pokharel added a comment - Thanks for the information. We were going to upgrade JIRA after June 15. We might just wait 10 more days then if the dates for 6.0.3 doesn't change.

            Eric Dalgliesh added a comment -

            6.0.3 is currently scheduled to be public on the 25th June. Whether to wait or not depends on how important this is for you.

            Eric Dalgliesh added a comment - 6.0.3 is currently scheduled to be public on the 25th June. Whether to wait or not depends on how important this is for you.

            Adhip Pokharel added a comment -

            Thanks for the information, Eric. It looks like it'll be fixed in version 6.0.3. We were planing to upgrade our Production instance of JIRA to 6.0.1 next week. If 6.0.3 will be released soon, should we wait until then as this issue is most likely to be addressed in that version?

            Adhip Pokharel added a comment - Thanks for the information, Eric. It looks like it'll be fixed in version 6.0.3. We were planing to upgrade our Production instance of JIRA to 6.0.1 next week. If 6.0.3 will be released soon, should we wait until then as this issue is most likely to be addressed in that version?

            Eric Dalgliesh added a comment -

            This issue is in progress, but it's turning out to be much thornier than we had anticipated. We don't have a definite date as yet.

            Eric Dalgliesh added a comment - This issue is in progress, but it's turning out to be much thornier than we had anticipated. We don't have a definite date as yet.

            Adhip Pokharel added a comment -

            Any updates when this will be fixed now that JIRA 6.0 is released??

            Thanks
            Ahdip

            Adhip Pokharel added a comment - Any updates when this will be fixed now that JIRA 6.0 is released?? Thanks Ahdip

            Michelle Barry added a comment - - edited

            Hi,
            We are experiencing this problem and the custom date time fields are configured for us to use in conjunction with VertygoSLA plug-in.
            For us this is much higher than a 'Minor' priority becuase the dates are used to set the SLA due dates (often a matter of hours) which have a financial penalty associated with them. Whilst we can tell users to be careful when setting the date time fields, this is a manual workaround and if errors happen we as an organisation could lose credibility with our clients.
            Please can you give an indication of when this issue may be resolved.
            Regards
            Michelle

            Michelle Barry added a comment - - edited Hi, We are experiencing this problem and the custom date time fields are configured for us to use in conjunction with VertygoSLA plug-in. For us this is much higher than a 'Minor' priority becuase the dates are used to set the SLA due dates (often a matter of hours) which have a financial penalty associated with them. Whilst we can tell users to be careful when setting the date time fields, this is a manual workaround and if errors happen we as an organisation could lose credibility with our clients. Please can you give an indication of when this issue may be resolved. Regards Michelle

            Eric Dalgliesh added a comment -

            Hi apokharel@fncinc.com and lucgauf,

            Thanks for your feedback. Priority is only one of the inputs into what order we should fix bugs. Interaction like this is another. Addtionally there are currently four customers with comments on this issue and 6 votes. Those are not insignificant numbers (though they also are certainly not the highest), and you obviously still care about this bug, so I'm going to add it to the backlog.

            If you're after timelines, there are just over 200 other issues on that shorter term backlog at the moment so this is unlikely to get fixed before 6.0 is released, making the most likely schedule for this at some stage in the 6.0.x lifecycle. We don't usually give estimates of when things will be fixed because they turn out to be wildly inaccurate most of the time, so please bear that in mind when considering this.

            Regards,
            Eric

            Eric Dalgliesh added a comment - Hi apokharel@fncinc.com and lucgauf , Thanks for your feedback. Priority is only one of the inputs into what order we should fix bugs. Interaction like this is another. Addtionally there are currently four customers with comments on this issue and 6 votes. Those are not insignificant numbers (though they also are certainly not the highest), and you obviously still care about this bug, so I'm going to add it to the backlog. If you're after timelines, there are just over 200 other issues on that shorter term backlog at the moment so this is unlikely to get fixed before 6.0 is released, making the most likely schedule for this at some stage in the 6.0.x lifecycle. We don't usually give estimates of when things will be fixed because they turn out to be wildly inaccurate most of the time, so please bear that in mind when considering this. Regards, Eric

            Adhip Pokharel added a comment -

            Hi Eric,

            You are absolutely right on classifying priority. My personal thinking is that "A bug is a bug". If this was a "New Feature Request", i would agree with you to classify them and take action on it according to priority. I personally believe all bugs should be fixed. I know this bug does not crash JIRA but is really annoying especially when you have more than 100 users using the Project where this "Custom Field" is used and being a JIRA Administrator, i get to face majority of their questions.

            My one simple question to you: How about if the Date/Time on your computer is screwed up and you have to manually change it every time? That does not crash your computer from operating but is that not annoying to you to change your Date/Time every time?

            Thanks
            Adhip

            Adhip Pokharel added a comment - Hi Eric, You are absolutely right on classifying priority. My personal thinking is that "A bug is a bug". If this was a "New Feature Request", i would agree with you to classify them and take action on it according to priority. I personally believe all bugs should be fixed. I know this bug does not crash JIRA but is really annoying especially when you have more than 100 users using the Project where this "Custom Field" is used and being a JIRA Administrator, i get to face majority of their questions. My one simple question to you: How about if the Date/Time on your computer is screwed up and you have to manually change it every time? That does not crash your computer from operating but is that not annoying to you to change your Date/Time every time? Thanks Adhip

            luc gaufreteau added a comment -

            Hi Eric,

            Yes, you're right on the explanation of the classification of the issues.

            My irritation is due to the treatment of these issues.

            Now, we can understand that this issues will not be treated and it's the case of many others.

            I can understand that it is more exciting to work on new functionalities, new UI...
            But if Atlassian wants to impose its tools in a professional world, the issues have to be treated.

            Another thing, the corrections are made in the most recent version of JIRA. We can't benefit from these corrections: our JIRA instances must be surcharged to compensate for the lack of issues resolution by the editor. Consequently, the migrations towards a new version of JIRA are too expensive to be done regularly.

            For my users, an issue like this one is not acceptable and it becomes increasingly difficult to support a solution “not professional enough”.

            Best regards,
            Luc

            luc gaufreteau added a comment - Hi Eric, Yes, you're right on the explanation of the classification of the issues. My irritation is due to the treatment of these issues. Now, we can understand that this issues will not be treated and it's the case of many others. I can understand that it is more exciting to work on new functionalities, new UI... But if Atlassian wants to impose its tools in a professional world, the issues have to be treated. Another thing, the corrections are made in the most recent version of JIRA. We can't benefit from these corrections: our JIRA instances must be surcharged to compensate for the lack of issues resolution by the editor. Consequently, the migrations towards a new version of JIRA are too expensive to be done regularly. For my users, an issue like this one is not acceptable and it becomes increasingly difficult to support a solution “not professional enough”. Best regards, Luc

            Eric Dalgliesh added a comment -

            Hi lucgauf,

            Here's a sanitised version of a private comment I made a few minutes ago. I hope it helps explain why I've classified this issue as I have.

            Blocker: Blocks development and/or testing work, production could not run.
            Critical: Crashes, loss of data, severe memory leak.
            Major: Major loss of function.
            Minor: Minor loss of function, or other problem where easy workaround is present.
            Trivial: Cosmetic problem like misspelt words or misaligned text.

            This issue doesn't stop JIRA from running, and it doesn't cause crashes or data loss; so major is the highest that this can reasonably be classified at. Yes, Major means that a piece of functionality is missing - that's what makes it Major. Major is not equivalent to medium priority - it still describes something that is quite important. In this case it would be something like "Due date cannot be set". Minor applies to a situation where there is a fairly simple workaround present - in this case you should be able to work around the issue by setting the time manually.

            Please let me know if I've misunderstood something about the issue.

            Regards,
            Eric

            Eric Dalgliesh added a comment - Hi lucgauf , Here's a sanitised version of a private comment I made a few minutes ago. I hope it helps explain why I've classified this issue as I have. Blocker: Blocks development and/or testing work, production could not run. Critical: Crashes, loss of data, severe memory leak. Major: Major loss of function. Minor: Minor loss of function, or other problem where easy workaround is present. Trivial: Cosmetic problem like misspelt words or misaligned text. This issue doesn't stop JIRA from running, and it doesn't cause crashes or data loss; so major is the highest that this can reasonably be classified at. Yes, Major means that a piece of functionality is missing - that's what makes it Major. Major is not equivalent to medium priority - it still describes something that is quite important. In this case it would be something like "Due date cannot be set". Minor applies to a situation where there is a fairly simple workaround present - in this case you should be able to work around the issue by setting the time manually. Please let me know if I've misunderstood something about the issue. Regards, Eric

            luc gaufreteau added a comment -

            Minor -> Blocker -> Major -> Minor -> ?

            Seriously this bug IS a problem !

            luc gaufreteau added a comment - Minor -> Blocker -> Major -> Minor -> ? Seriously this bug IS a problem !

            Brahim CHERKAOUI added a comment - - edited

            I'm finding the same with my Jira 4.4.3 instance, could we have a solution to this bug created on November 2011 ?

            Brahim CHERKAOUI added a comment - - edited I'm finding the same with my Jira 4.4.3 instance, could we have a solution to this bug created on November 2011 ?

            Anthony Fok added a comment - - edited

            I'm finding the same as David: picker works correctly under Firefox, but IE9 and Chrome (as well as Safari and Opera) both cause an extra +10 hour offset (my server, JIRA default, JIRA user profile, and desktop are all set to +10 GMT)

            Anthony Fok added a comment - - edited I'm finding the same as David: picker works correctly under Firefox, but IE9 and Chrome (as well as Safari and Opera) both cause an extra +10 hour offset (my server, JIRA default, JIRA user profile, and desktop are all set to +10 GMT)

            Dave C added a comment -

            This appears to work correctly in Firefox, but not IE9 and Chrome.

            Dave C added a comment - This appears to work correctly in Firefox, but not IE9 and Chrome.

            Jon Abad added a comment - - edited

            In my instance of JIRA 4.4.3, my system default and user timezone are both GMT -5 (America/New York) but my date pickers, both custom and built in are showing GMT -10.

            Jon Abad added a comment - - edited In my instance of JIRA 4.4.3, my system default and user timezone are both GMT -5 (America/New York) but my date pickers, both custom and built in are showing GMT -10.

              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              itse Ivan Tse
              Affected customers:
              7 This affects my team
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: