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
        Thom Nichols added a comment -

        On second thought, adding methods to calendar seems a little overkill, since you could just say

        calendar.time.format(...)

        and DateFormat doesn't work on Calendar instances anyway.

        Show
        Thom Nichols added a comment - On second thought, adding methods to calendar seems a little overkill, since you could just say calendar.time.format(...) and DateFormat doesn't work on Calendar instances anyway.
        Hide
        Thom Nichols added a comment -

        Implemented:

        new Date().format( 'yyyy-MM-dd' ) 
        new Date().dateString     // 02/10/70 (en_UK)
        new Date().timeString     // 10:00:00
        new Date().dateTimeString // 02/10/70 10:00:00
        

        I chose to use DateTime.SHORT for the date portion and DateTime.MEDIUM for the time portion – it seems more useful than the Java API defaults for DateFormat.getDateInstance/ DateFormat.getTimeInstance/ DateFormat.getDateTimeInstance.... And why is there another DateFormat.getInstance anyway??

        Show
        Thom Nichols added a comment - Implemented: new Date().format( 'yyyy-MM-dd' ) new Date().dateString // 02/10/70 (en_UK) new Date().timeString // 10:00:00 new Date().dateTimeString // 02/10/70 10:00:00 I chose to use DateTime.SHORT for the date portion and DateTime.MEDIUM for the time portion – it seems more useful than the Java API defaults for DateFormat.getDateInstance/ DateFormat.getTimeInstance/ DateFormat.getDateTimeInstance.... And why is there another DateFormat.getInstance anyway??
        Hide
        Paul King added a comment -

        Yes, parse would be good too.

        Show
        Paul King added a comment - Yes, parse would be good too.
        Hide
        Paul King added a comment -

        The other alternative to format would be a toString with an arg, i.e.:

        new Date().toString( 'yyyy-MM-dd' )
        
        Show
        Paul King added a comment - The other alternative to format would be a toString with an arg, i.e.: new Date().toString( 'yyyy-MM-dd' )
        Hide
        Thom Nichols added a comment -

        I thought toString with args would be odd- I can't recall any other API that overloads the toString method. format seemed reasonable enough since it seems to follow DateFormat, String.format() in Java5, etc.

        As for parse, it is probably best as a static method, i.e. Date.parse( format, input ), that returns a new Date instance – right?

        Show
        Thom Nichols added a comment - I thought toString with args would be odd- I can't recall any other API that overloads the toString method. format seemed reasonable enough since it seems to follow DateFormat , String.format() in Java5, etc. As for parse , it is probably best as a static method, i.e. Date.parse( format, input ) , that returns a new Date instance – right?
        Hide
        Thom Nichols added a comment -

        I am going to change my mind yet again on adding these methods to Calendar. cal.time.format(..) wouldn't quite work because, while your calendar instance might have a certain TimeZone and Locale, converting to Date first essentially drops this information, and the date/time will always print using the system locale and TZ.

        The only problem is, Calendar does not have a getLocale method. So while you can definitely set a locale on a Calendar, I can't get access to it in order to pass that information on to the DateFormat instance. If nothing else, the TimeZone will be adjusted correctly when calling cal.format(..), which should be an improvement. But the methods that rely on a 'locale specific default format' (getDateString, getTimeString, getDateTimeString) will not have the calendar's locale information, unless there is some hacky work-around somebody knows of.

        Show
        Thom Nichols added a comment - I am going to change my mind yet again on adding these methods to Calendar. cal.time.format(..) wouldn't quite work because, while your calendar instance might have a certain TimeZone and Locale, converting to Date first essentially drops this information, and the date/time will always print using the system locale and TZ. The only problem is, Calendar does not have a getLocale method. So while you can definitely set a locale on a Calendar, I can't get access to it in order to pass that information on to the DateFormat instance. If nothing else, the TimeZone will be adjusted correctly when calling cal.format(..) , which should be an improvement. But the methods that rely on a 'locale specific default format' (getDateString, getTimeString, getDateTimeString) will not have the calendar's locale information, unless there is some hacky work-around somebody knows of.
        Hide
        Jim White added a comment -

        Is this on track to merge to 1.6? It is currently the only diff btw the two versions.

        Show
        Jim White added a comment - Is this on track to merge to 1.6? It is currently the only diff btw the two versions.
        Hide
        Guillaume Laforge added a comment -

        Would be nice to have in 1.6, yes.

        Show
        Guillaume Laforge added a comment - Would be nice to have in 1.6, yes.
        Hide
        Thom Nichols added a comment -

        It appears to already be in 1.5.7, so I assume it would be in 1.6 too

        Show
        Thom Nichols added a comment - It appears to already be in 1.5.7, so I assume it would be in 1.6 too
        Hide
        Thom Nichols added a comment -

        Although now that I take another look, it appears that Calendar.format is not in 1.5.7. But the Date methods definitely are.

        Show
        Thom Nichols added a comment - Although now that I take another look, it appears that Calendar.format is not in 1.5.7. But the Date methods definitely are.
        Hide
        Thom Nichols added a comment -

        This has been added to the 1.5.7 API, so I what's been done should be considered complete.

        Show
        Thom Nichols added a comment - This has been added to the 1.5.7 API, so I what's been done should be considered complete.
        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: