Implement Date format GDK methods

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.

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??

Yes, parse would be good too.

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

new Date().toString( 'yyyy-MM-dd' )

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?

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.

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

Would be nice to have in 1.6, yes.

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

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

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

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.

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.

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.

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.