groovy
  1. groovy
  2. GROOVY-3066

Implement Date format GDK methods

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.7
    • Component/s: groovy-jdk
    • Labels:
      None
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      2

      Description

      GDK convenience methods to wrap SimpleDateFormat such as {{ new Date().format( 'yyyy-MM-dd' )}}.

      These should probably added for Calendar too.

      Would a complimentary 'parse' method be appropriate?

      1. DateFormatGTK-patch.txt
        13 kB
        Thom Nichols
      2. DateGDKTest.groovy
        1 kB
        Thom Nichols

        Activity

        Hide
        Jim White added a comment -

        I would like to change this before it becomes public API.

        This change introduces a method Date.format(String). I was just looking to propose the addition of a general format method based on String.format(String, Object[]). I think that would be a more generally useful and consistent approach.

        Show
        Jim White added a comment - I would like to change this before it becomes public API. This change introduces a method Date.format(String). I was just looking to propose the addition of a general format method based on String.format(String, Object[]). I think that would be a more generally useful and consistent approach.
        Hide
        Thom Nichols added a comment -

        Well, for one, I it looks like Date.format is already part of 1.5.7:
        http://groovy.codehaus.org/groovy-jdk/java/util/Date.html#format(java.lang.String%20format)

        Second, the string format for Date is not nearly as clean, a string format would look like this: "%tY/%<$tm/%<$te ....." which is much more difficult to read. While a general Object.format(...) method might be a good idea, that should be a different proposal. If it is accepted, then another issue can be opened to deal with the Date methods. Personally I would keep them as-is.

        Show
        Thom Nichols added a comment - Well, for one, I it looks like Date.format is already part of 1.5.7: http://groovy.codehaus.org/groovy-jdk/java/util/Date.html#format(java.lang.String%20format ) Second, the string format for Date is not nearly as clean, a string format would look like this: "%tY/%<$tm/%<$te ....." which is much more difficult to read. While a general Object.format(...) method might be a good idea, that should be a different proposal. If it is accepted, then another issue can be opened to deal with the Date methods. Personally I would keep them as-is.
        Hide
        Jim White added a comment -

        I agree the printf style format strings are not nearly as pretty for dates as SimpleDateFormat. I would like to see a general picture style formatter too, but Java doesn't have one (at least not part of standard Java).

        I noticed after I posted that 1.5.7 was indeed recently released. That is unfortunate and I wish that such an important method name as 'format' had received more review and this conflict with String.format had been caught.

        And while it would be legitimate to have a breaking change on this in 1.6, the good news is it occurred to me that we can have both.

        Naturally I had originally thought that the format string would simply be a format specifier for a single argument (self), but we could instead look for '%' occurring in the format string.

        For Date, if it is not present we can use SimpleDateFormat.

        For the other types we'll prefix the format string with a "% if one is not present.

        And as you say implementing Object.format is a new issue, but I started here because of the conflict.

        Show
        Jim White added a comment - I agree the printf style format strings are not nearly as pretty for dates as SimpleDateFormat. I would like to see a general picture style formatter too, but Java doesn't have one (at least not part of standard Java). I noticed after I posted that 1.5.7 was indeed recently released. That is unfortunate and I wish that such an important method name as 'format' had received more review and this conflict with String.format had been caught. And while it would be legitimate to have a breaking change on this in 1.6, the good news is it occurred to me that we can have both. Naturally I had originally thought that the format string would simply be a format specifier for a single argument (self), but we could instead look for '%' occurring in the format string. For Date, if it is not present we can use SimpleDateFormat. For the other types we'll prefix the format string with a "% if one is not present. And as you say implementing Object.format is a new issue, but I started here because of the conflict.
        Hide
        Thom Nichols added a comment -

        So what happens if you want a '%' character in your output? You'd have to make up some escaping rules or something then. Not that it would be likely, but still, I think trying to support two very different format patterns could be ugly.

        I'm going to re-close this issue. If a general-purpose format method is accepted and creates a conflict with this API, then a separate issue can be opened to change the behavior that targets 1.6 (or whatever version the 'format' API is slated for). Is there a JIRA issue open for this enhancement? Has it been discussed on the mailing list? I'll put a link here if one exists (just for reference) but the discussion should probably be carried out elsewhere.

        Show
        Thom Nichols added a comment - So what happens if you want a '%' character in your output? You'd have to make up some escaping rules or something then. Not that it would be likely, but still, I think trying to support two very different format patterns could be ugly. I'm going to re-close this issue. If a general-purpose format method is accepted and creates a conflict with this API, then a separate issue can be opened to change the behavior that targets 1.6 (or whatever version the 'format' API is slated for). Is there a JIRA issue open for this enhancement? Has it been discussed on the mailing list? I'll put a link here if one exists (just for reference) but the discussion should probably be carried out elsewhere.
        Hide
        Jim White added a comment -

        Well, go ahead and resolve if you like (note the recent thread on resolve vs. close).

        But I would rather see the SimpleDateFormat form of Date.format dropped (renamed or whatever) than have it interfere with a behavior that is more generally useful and more in line with the Java standard. I see that you noted the existence of String.format method in one of the comments. That should have been reason enough to pick a different name.

        Something like 'picture' could make sense with the view to eventually having a more general scheme for that style. In fact this JIRA should be expanded to cover java.text.DecimalFormat as well as java.text.SimpleDateFormat. j.t.ChoiceFormat probably belongs too, but I haven't looked at how it might work.

        But being the big advocate of backwards compatibility that I am, I'm willing to accept that having a '%' in a format blocks the SimpleDateFormat use in the interest of preserving your usage over API purity.

        I'll open the JIRA when I have some code.

        Show
        Jim White added a comment - Well, go ahead and resolve if you like (note the recent thread on resolve vs. close). But I would rather see the SimpleDateFormat form of Date.format dropped (renamed or whatever) than have it interfere with a behavior that is more generally useful and more in line with the Java standard. I see that you noted the existence of String.format method in one of the comments. That should have been reason enough to pick a different name. Something like 'picture' could make sense with the view to eventually having a more general scheme for that style. In fact this JIRA should be expanded to cover java.text.DecimalFormat as well as java.text.SimpleDateFormat. j.t.ChoiceFormat probably belongs too, but I haven't looked at how it might work. But being the big advocate of backwards compatibility that I am, I'm willing to accept that having a '%' in a format blocks the SimpleDateFormat use in the interest of preserving your usage over API purity. I'll open the JIRA when I have some code.

          People

          • Assignee:
            Thom Nichols
            Reporter:
            Thom Nichols
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: