I dont get this part. You used sql date ( is not this should be util date ? ) and milliseconds . ..how does this optimize ?
for_yan
java.sql.Date has toString() method which happened to format it just as you need
2012-07-14
If you use java.util.Date() the toString() method will be different and with seconds and so on, that's why CEHJ used java.sql.Date() here
You can use any of those solutions.
Calendar maybe a little bit newer and it is a standard, so
its bugs are not so well known.
The probability that you encounter bugs with leap years is much less than bugs from hundred other sources,
and the advantage of java.util.Date is that it is much more intuitive, whereas
with Calendar you need to go to API to check how to write it, no matter how many times you use it.
At least for me it is this way.
>>I dont get this part. You used sql date ( is not this should be util date ? ) and milliseconds . ..how does this optimize ?
The optimisation is
a. avoiding the use of DateFormat (known to be slow - so much so that other apis have been written to do it)
b. writing less code ;)
>>You used sql date
Since its toString method gives you the format you need
cofactor
ASKER
I dont have a leap year constraint. the idea was to find a date advance than current date. ...it need not have to be exactly 1 year though ( with leap year).
Please post the code that you are now going to use, cofactor, for the benefit of future visitors to this question
rrz
In my opinion, cofactor should have accepted http:#36188279 as the solution.
I guess he was happy with the String manipulation posted by for_yan. Personally, I would have accepted CEHJ's http:#36189661. But, the customer is always right.
CEHJ
>>cofactor should have accepted http:#36188279 as the solution.
He should have accepted yours, with my adjustment ;)
This is checeked and working even without compiler warning.
You can do the same thing with Calendar but it is more straightforward and understandable with Date:
Open in new window
Open in new window