When I try to add 30 days with the date obtained in the Database is giving this error.
DateFormat df = new SimpleDateFormat("yyyy-MM-dd");
Date today = Calendar.getInstance().getTime();
String reportDate = df.format(today);
String endDay = rset.getString("vip_end");
endDay.add(Calendar.DAY_OF_MONTH, 30)
Error
Error:(76, 70) java: cannot find symbol
symbol: method add(int,int)
location: variable endDay of type java.lang.String
LocalDate // Represent a date-only value, without time-of-day and without time zone.
.now( // Capture the current date as seen in the wall-clock time used by the people of a particular region (a time zone).
ZoneId.of( "Asia/Tokyo" ) // Specify your time zone. Use proper `Continent/Region` names, never 2-4 character pseudo-zones such as IST or PST or EST or CST.
) // Returns a `LocalDate` object.
.plusDays( 30 ) // Add days to determine a later date. Returns a new `LocalDate` object rather than mutating the original.
.toString() // Generate text representing the value of this `LocalDate` object, in standard ISO 8601 format YYYY-MM-DD.
2019-06-30
add method on StringYou declared endDay to be a String. Then you called the method add. But there is no method add on String class. Thus your error, as explained in the error message.
You are using terrible date-time classes that were supplanted years ago by the modern java.time classes with the adoption of JSR 310. Stop doing that.
The LocalDate class represents a date-only value without time-of-day and without time zone or offset-from-UTC.
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment during runtime(!), so your results may vary. Better to specify your desired/expected time zone explicitly as an argument. If critical, confirm the zone with your user.
Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the code becomes ambiguous to read in that we do not know for certain if you intended to use the default or if you, like so many programmers, were unaware of the issue.
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
Or specify a date. You may set the month by a number, with sane numbering 1-12 for January-December.
LocalDate ld = LocalDate.of( 1986 , 2 , 23 ) ; // Years use sane direct numbering (1986 means year 1986). Months use sane numbering, 1-12 for January-December.
Or, better, use the Month enum objects pre-defined, one for each month of the year. Tip: Use these Month objects throughout your codebase rather than a mere integer number to make your code more self-documenting, ensure valid values, and provide type-safety. Ditto for Year & YearMonth.
LocalDate ld = LocalDate.of( 1986 , Month.FEBRUARY , 23 ) ;
Your output format is in standard ISO 8601 format. This format is used by default in the LocalDate class for parsing/generating strings. So no need to specify a formatting pattern.
String output = LocalDate.of( 2019 , Month.JANUARY , 23 ).toString() ;
2019-01-23
Add 30 days.
LocalDate today = LocalDate.now( ZoneId.of( "Africa/Tunis" ) ) ;
LocalDate later = today.plusDays( 30 ) ;
The java.time classes follow the immutable objects pattern. So they return a new fresh object based on the values of the original.
