OFBiz
  1. OFBiz
  2. OFBIZ-1361

Mark UtilDateTime.java deprecated methods as deprecated

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None

      Description

      Now that user-selected locale and time support has been added to the framework, it's time to start weeding out date/time code that doesn't use the Locale and TimeZone objects.

        Issue Links

          Activity

          Hide
          Adrian Crum added a comment -

          I'm removing myself from this issue because it is too controversial. If someone else wants to work on it they are welcome to do so.

          Show
          Adrian Crum added a comment - I'm removing myself from this issue because it is too controversial. If someone else wants to work on it they are welcome to do so.
          Hide
          Jacques Le Roux added a comment -

          Hi Adrian,

          Cool, please feel free and thanks

          Show
          Jacques Le Roux added a comment - Hi Adrian, Cool, please feel free and thanks
          Hide
          Adrian Crum added a comment -

          Jacques,

          Since you assigned it to me, I assumed I would be working on it.

          Hold off on any commits, I'm updating UtilDateTime to provide easy-to-use alternatives to the planned deprecated methods.

          Show
          Adrian Crum added a comment - Jacques, Since you assigned it to me, I assumed I would be working on it. Hold off on any commits, I'm updating UtilDateTime to provide easy-to-use alternatives to the planned deprecated methods.
          Hide
          Jacques Le Roux added a comment -

          To be clear, I second Adrian's proposition to deprecate these methods and I will do soon if nobody stops me.

          Show
          Jacques Le Roux added a comment - To be clear, I second Adrian's proposition to deprecate these methods and I will do soon if nobody stops me.
          Hide
          Jacques Le Roux added a comment -

          From discussion in https://issues.apache.org/jira/browse/OFBIZ-2177 I think it's time to reopen this issue

          Show
          Jacques Le Roux added a comment - From discussion in https://issues.apache.org/jira/browse/OFBIZ-2177 I think it's time to reopen this issue
          Hide
          Adrian Crum added a comment -

          Due to differences in opinion and no clear consensus, I'm closing this. We can look at it again later.

          Show
          Adrian Crum added a comment - Due to differences in opinion and no clear consensus, I'm closing this. We can look at it again later.
          Hide
          Jacques Le Roux added a comment -

          David,

          I agree with David and Jeremy. Deprecating ans documenting it in code seems a good idea in this case. There are better chances to be read than in the Best practices Guides (pragmatic POV) which does not mean that this should not be documented at this higher level too. Is there something else we are missing ?

          Show
          Jacques Le Roux added a comment - David, I agree with David and Jeremy. Deprecating ans documenting it in code seems a good idea in this case. There are better chances to be read than in the Best practices Guides (pragmatic POV) which does not mean that this should not be documented at this higher level too. Is there something else we are missing ?
          Hide
          Wickersheimer Jeremy added a comment -

          David, i understand your point but marking the methods deprecated doesn't remove them, so they can still be used.
          However they should not be used, as Adrian points out they do not use the correct locale so there output will be inconsistent. Marking the deprecated is a good way to say that the code using them should be migrated at, and it would also make the compiler throw out useful warnings.

          Show
          Wickersheimer Jeremy added a comment - David, i understand your point but marking the methods deprecated doesn't remove them, so they can still be used. However they should not be used, as Adrian points out they do not use the correct locale so there output will be inconsistent. Marking the deprecated is a good way to say that the code using them should be migrated at, and it would also make the compiler throw out useful warnings.
          Hide
          Adrian Crum added a comment -

          David,

          Thanks for your input. I don't understand what you're saying though.

          If those methods aren't deprecated, then developers will continue to use them. This will lead to problems down the road with inconsistent data - users are going to encounter two different results for the same date/time criteria. Are you saying inconsistent data is something we should allow?

          Show
          Adrian Crum added a comment - David, Thanks for your input. I don't understand what you're saying though. If those methods aren't deprecated, then developers will continue to use them. This will lead to problems down the road with inconsistent data - users are going to encounter two different results for the same date/time criteria. Are you saying inconsistent data is something we should allow?
          Hide
          David E. Jones added a comment -

          While I agree that this should be the best practice, there is a big difference in the framework between what we "allow" and what we "recommend".

          There is lots of stuff you can do with the framework that is really not a good idea, thought some might disagree. Things that we recommend should be documented in the Best Practices Guide. Other things we don't want to make more difficult, IMO, that this is important because of the comment about disagreement above. There are pretty much always good reasons why we do things the way we recommend in the framework, but those recommendations have evolved over time and will continue to evolve as well, and not allowing things we don't recommend stifles this and limits opportunity to progress and improve.

          That is of course a generality, and there is a clear best practice here that should be documented and it probably won't ever change, but I'm still against forcing on a matter of principle.

          Show
          David E. Jones added a comment - While I agree that this should be the best practice, there is a big difference in the framework between what we "allow" and what we "recommend". There is lots of stuff you can do with the framework that is really not a good idea, thought some might disagree. Things that we recommend should be documented in the Best Practices Guide. Other things we don't want to make more difficult, IMO, that this is important because of the comment about disagreement above. There are pretty much always good reasons why we do things the way we recommend in the framework, but those recommendations have evolved over time and will continue to evolve as well, and not allowing things we don't recommend stifles this and limits opportunity to progress and improve. That is of course a generality, and there is a clear best practice here that should be documented and it probably won't ever change, but I'm still against forcing on a matter of principle.
          Hide
          Adrian Crum added a comment -

          Attached patch deprecates the UtilDateTime.java methods that shouldn't be used.

          Show
          Adrian Crum added a comment - Attached patch deprecates the UtilDateTime.java methods that shouldn't be used.

            People

            • Assignee:
              Unassigned
              Reporter:
              Adrian Crum
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development