I have a Java problem where I need to check if an item has expired. This is supposed to check if the item is at least x (x is an integer and can be set to any integer value) months old.
Just to reclarify Supposing I have a pack of eggs, I want to check if it has been 1 months since I added them (dateAdded).
I wrote a simple comparison but it doesn't seem to give the correct response. Here is the code.
public Boolean isEndOfLine() {
Calendar today = Calendar.getInstance();
if(today.compareTo(dateAdded) >= END_OF_LINE) {
return true;
} else {
return false;
}
}
The value of end of line is an integer 12 i.e 12 months.
I do not hold javadoc in my head, but along the lines of:
dateAdded.add(Calendar.Month, END_OF_LINE).compareTo(today) > 0
Here's some similar example code, but using the Joda-Time 2.3 library.
FYI:
A Joda-Time DateTime instance knows its own time zone.
The minusMonths method is smart, handles Daylight Saving Time and other issues. You may want to read its source code to verify its logic follows your business rules as to what "x number of months ago" means.
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
// import org.joda.time.*;
// import org.joda.time.format.*;
// Better to specify a time zone explicitly rather than rely on default.
// Time Zone list… http://joda-time.sourceforge.net/timezones.html (not quite up-to-date, read page for details)
DateTimeZone timeZone = DateTimeZone.forID( "Europe/Paris" );
int countMonths = 2;
DateTime now = new DateTime( timeZone );
// If you want to include the entire day, get first moment of the day by calling "withTimeAtStartOfDay".
DateTime someMonthsAgo = now.minusMonths( countMonths ).withTimeAtStartOfDay();
DateTime dateAdded = new DateTime( 2013, 5, 6, 7, 8, 9, timeZone ); // Arbitrary values for example.
// If 'dateAdded' happened prior to our target date-time 'someMonthsAgo', the pack of eggs is expired.
Boolean isEndOfLine = dateAdded.isBefore( someMonthsAgo );
Dump to console…
System.out.println( "now: " + now );
System.out.println( "someMonthsAgo: " + someMonthsAgo );
System.out.println( "dateAdded: " + dateAdded );
System.out.println( "isEndOfLine: " + isEndOfLine );
When run…
now: 2014-01-08T21:36:11.179+01:00
someMonthsAgo: 2013-11-08T00:00:00.000+01:00
dateAdded: 2013-05-06T07:08:09.000+02:00
isEndOfLine: true
as mentioned in the Calendar docs
You should not rely on the number returned by compareTo - you just know that if it is greater than 0 that the original date is greater.
So create a new date (x months in the passed) and compare to that one.
The method returns 0 if the time represented by the argument is equal to the time represented by this Calendar object; or a value less than 0 if the time of this Calendar is before the time represented by the argument; or a value greater than 0 if the time of this Calendar is after the time represented.
import java.util.*;
public class CalendarDemo {
public static void main(String[] args) {
// create two calendar at the different dates
Calendar cal1 = new GregorianCalendar(2015, 8, 15);
Calendar cal2 = new GregorianCalendar(2008, 1, 02);
// compare the time values represented by two calendar objects.
int i = cal1.compareTo(cal2);
// return positive value if equals else return negative value
System.out.println("The result is :"+i);
// compare again but with the two calendars swapped
int j = cal2.compareTo(cal);
// return positive value if equals else return negative value
System.out.println("The result is :" + j);
}
}
Here is the working solution. Tested with JUNIT to confirm results.
public Boolean isEndOfLine() {
Calendar today = Calendar.getInstance();
today.add(Calendar.MONTH, -END_OF_LINE);
return today.compareTo(dateAdded) >= 0;
}
I subtracted the END_OF_LINE from today using the add method. Notice the minus on line 3. I then compared to see if it is greater than 0. Thanks for all your suggestions.
Related
I am trying to calculate the difference between two LocalDate objects and the result seems to be off, but not every time.
I am using the Period construct. The below code shows one example which returns the expected result (I got that here) and another one which gives me the "wrong" result. I put that in quotes because I am not sure if that truly is wrong, or if the expected value is wrong. Note however, that if I use the online calculator from calculator.net, that gives me the result I expect.
public void manualTestPeriodBetween() {
//works fine - expected result obtained
LocalDate start = LocalDate.of(2014, 2, 14);
LocalDate end = LocalDate.of(2017, 8, 1);
Period result = Period.between(start, end);
Period expected = Period.of(3, 5, 18);
checkPeriods(expected, result);
//does not work as expected
start = LocalDate.of(2017, 5, 19);
end = LocalDate.of(2019, 7, 13);
result = Period.between(start, end);
expected = Period.of(2, 1, 25);
checkPeriods(expected, result);
}
private void checkPeriods(Period expected, Period result) {
System.out.println("expected Period = " + expected + ", resulting Period = " + result);
if (result.equals(expected)) {
System.out.println("SUCCESS - result Period matches expected");
} else {
System.out.println("FAIL - result Period not matched");
}
}
Output:
expected Period = P3Y5M18D, resulting Period = P3Y5M18D
SUCCESS - result Period matches expected
expected Period = P2Y1M25D, resulting Period = P2Y1M24D
FAIL - result Period not matched
Can someone help me figure out whether I am missing something or the expected result is wrong (both in my code and the online date calculator)? or maybe something else I am not even considering.
Here is a screenshot of the results obtained from the online date calculator:
The online date calculator you have provided may have been implemented incorrectly. From my favorite time resource, timeanddate
From and including: Friday, May 19, 2017
To, but not including Saturday, July 13, 2019
Result: 785 days
It is 785 days from the start date to the end date, but not including the end date.
Or 2 years, 1 month, 24 days excluding the end date.
Or 25 month, 24 days excluding the end date.
This is identical to the response provided by thecalculatorsite.com
I don't have the implementation for your online calculator, but the discrepancy appears to occur because May is a 31-day month.
It looks to be calculating the day-difference before the month difference, using some mathematical assumption for month length.
The Java method uses epochday to calculate the distances between two days in case of underflow, rather than adding an arbitrary value to offset a month.
if (totalMonths > 0 && days < 0) {
totalMonths--;
LocalDate calcDate = this.plusMonths(totalMonths);
days = (int) (end.toEpochDay() - calcDate.toEpochDay()); // safe
} else if (totalMonths < 0 && days > 0) {
totalMonths++;
days -= end.lengthOfMonth();
I mean, it should be 24 days depending on how you do the calculations.
If you add a month to get to june 19th, and june has 30 days- then it's only 24 days between the two dates.
https://www.wolframalpha.com/input/?i=days+between+5%2F19%2F2017+and+7%2F13%2F2019
The website you are checking it against is wrong, I can think of several ways that could happen depending on how they are implementing their date difference functions.
I'm trying to parse a date from a String.
I'd like to identify the case where due to daylight savings, the clocks go back and a time is effectively "repeated" in the same day.
For example, based on UK daylight savings time, the clocks go back an hour at 2AM, 27/10/2019.
Therefore:
12:30AM 27/10/2019,
One hour later - 1:30AM 27/10/2019,
One hour later - 1:30AM 27/10/2019 (as at 2AM, we went back an hour),
One hour later - 2:30AM 27/10/2019.
Therefore "1:30AM 27/10/2019" is referring to two different times. This is the case I am trying to identify.
I have created the following, but it uses Date & Calendar classes, and some deprecated methods. I'd like to do this using the new java.time functionality - and I'm hoping there's an easier solution.
public static boolean isDateRepeatedDST(final Date date, TimeZone timeZone) {
if (timeZone == null) {
// If not specified, use system default
timeZone = TimeZone.getDefault();
}
if (timeZone.useDaylightTime()) {
// Initially, add the DST offset to supplied date
// Handling the case where this is the first occurrence
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
calendar.add(Calendar.MILLISECOND, timeZone.getDSTSavings());
// And determine if they are now logically equivalent
if (date.toLocaleString().equals(calendar.getTime().toLocaleString())) {
return true;
} else {
// Then try subtracting the DST offset
// Handling the second occurrence
calendar = Calendar.getInstance();
calendar.setTime(date);
calendar.add(Calendar.MILLISECOND, -timeZone.getDSTSavings());
if (date.toLocaleString().equals(calendar.getTime().toLocaleString())) {
return true;
}
}
}
// Otherwise
return false;
}
ZoneId zone = ZoneId.of("Europe/London");
ZonedDateTime dateTime = ZonedDateTime.of(2019, 10, 27, 0, 30, 0, 0, zone);
for (int i = 0; i < 4; i++) {
System.out.println(dateTime);
dateTime = dateTime.plusHours(1);
}
Output:
2019-10-27T00:30+01:00[Europe/London]
2019-10-27T01:30+01:00[Europe/London]
2019-10-27T01:30Z[Europe/London]
2019-10-27T02:30Z[Europe/London]
You can see that the time 01:30 is repeated and that the offset is different the two times it comes.
If you want a test for whether a time is repeated:
public static boolean isDateRepeatedDST(ZonedDateTime dateTime) {
return ! dateTime.withEarlierOffsetAtOverlap().equals(dateTime.withLaterOffsetAtOverlap());
}
We can use it in the loop above if we modify the print statement:
System.out.format("%-37s %s%n", dateTime, isDateRepeatedDST(dateTime));
2019-10-27T00:30+01:00[Europe/London] false
2019-10-27T01:30+01:00[Europe/London] true
2019-10-27T01:30Z[Europe/London] true
2019-10-27T02:30Z[Europe/London] false
NOTE THIS IS NOT A DUPLICATE OF EITHER OF THE FOLLOWING
Calculating the difference between two Java date instances
calculate months between two dates in java [duplicate]
I have two dates:
Start date: "2016-08-31"
End date: "2016-11-30"
Its 91 days duration between the above two dates, I expected my code to return 3 months duration, but the below methods only returned 2 months. Does anyone have a better suggestion? Or do you guys think this is a bug in Java 8? 91 days the duration only return 2 months.
Thank you very much for the help.
Method 1:
Period diff = Period.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30"));
Method 2:
long daysBetween = ChronoUnit.MONTHS.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30"));
Method 3:
I tried to use Joda library instead of Java 8 APIs, it works. it loos will return 3, It looks like Java duration months calculation also used days value. But in my case, i cannot use the Joda at my project. So still looking for other solutions.
LocalDate dateBefore= LocalDate.parse("2016-08-31");
LocalDate dateAfter = LocalDate.parse("2016-11-30");
int months = Months.monthsBetween(dateBefore, dateAfter).getMonths();
System.out.println(months);
Since you don't care about the days in your case. You only want the number of month between two dates, use the documentation of the period to adapt the dates, it used the days as explain by Jacob. Simply set the days of both instance to the same value (the first day of the month)
Period diff = Period.between(
LocalDate.parse("2016-08-31").withDayOfMonth(1),
LocalDate.parse("2016-11-30").withDayOfMonth(1));
System.out.println(diff); //P3M
Same with the other solution :
long monthsBetween = ChronoUnit.MONTHS.between(
LocalDate.parse("2016-08-31").withDayOfMonth(1),
LocalDate.parse("2016-11-30").withDayOfMonth(1));
System.out.println(monthsBetween); //3
Edit from #Olivier Grégoire comment:
Instead of using a LocalDate and set the day to the first of the month, we can use YearMonth that doesn't use the unit of days.
long monthsBetween = ChronoUnit.MONTHS.between(
YearMonth.from(LocalDate.parse("2016-08-31")),
YearMonth.from(LocalDate.parse("2016-11-30"))
)
System.out.println(monthsBetween); //3
Since Java8:
ChronoUnit.MONTHS.between(startDate, endDate);
//Backward compatible with older Java
public static int monthsBetween(Date d1, Date d2){
if(d2==null || d1==null){
return -1;//Error
}
Calendar m_calendar=Calendar.getInstance();
m_calendar.setTime(d1);
int nMonth1=12*m_calendar.get(Calendar.YEAR)+m_calendar.get(Calendar.MONTH);
m_calendar.setTime(d2);
int nMonth2=12*m_calendar.get(Calendar.YEAR)+m_calendar.get(Calendar.MONTH);
return java.lang.Math.abs(nMonth2-nMonth1);
}
The documentation of Period#between states the following:
The start date is included, but the end date is not.
Furthermore:
A month is considered if the end day-of-month is greater than or equal to the start day-of-month.
Your end day-of-month 30 is not greater than or equal to your start day-of-month 31, so a third month is not considered.
Note the parameter names:
public static Period between(LocalDate startDateInclusive, LocalDate endDateExclusive)
To return 3 months, you can increment the endDateExclusive by a single day.
In case you want stick to java.time.Period API
As per java.time.Period documentation
Period between(LocalDate startDateInclusive, LocalDate endDateExclusive)
where
#param startDateInclusive the start date, inclusive, not null
#param endDateExclusive the end date, exclusive, not null
So it is better to adjust your implementation to make your end date inclusive and get your desired result
Period diff = Period.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30").plusDays(1));
System.out.println("Months : " + diff.getMonths());
//Output -> Months : 3
You have to be careful, never use LocalDateTime to calculate months between two dates the result is weird and incorrect, always use LocalDate !
here's is some code to prove the above:
package stack.time;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.temporal.ChronoUnit;
public class TestMonthsDateTime {
public static void main(String[] args) {
/**------------------Date Time----------------------------*/
LocalDateTime t1 = LocalDateTime.now();
LocalDateTime t2 = LocalDateTime.now().minusMonths(3);
long dateTimeDiff = ChronoUnit.MONTHS.between(t2, t1);
System.out.println("diff dateTime : " + dateTimeDiff); // diff dateTime : 2
/**-------------------------Date----------------------------*/
LocalDate t3 = LocalDate.now();
LocalDate t4 = LocalDate.now().minusMonths(3);
long dateDiff = ChronoUnit.MONTHS.between(t4, t3);
System.out.println("diff date : " + dateDiff); // diff date : 3
}
}
My 2%
This example checks to see if the second date is the end of that month. If it is the end of that month and if the first date of month is greater than the second month date it will know it will need to add 1
LocalDate date1 = LocalDate.parse("2016-08-31");
LocalDate date2 = LocalDate.parse("2016-11-30");
long monthsBetween = ChronoUnit.MONTHS.between(
date1,
date2);
if (date1.isBefore(date2)
&& date2.getDayOfMonth() == date2.lengthOfMonth()
&& date1.getDayOfMonth() > date2.getDayOfMonth()) {
monthsBetween += 1;
}
After the short investigation, still not totally fix my question, But I used a dirty solution to avoid return the incorrect duration. At least, we can get the reasonable duration months.
private static long durationMonths(LocalDate dateBefore, LocalDate dateAfter) {
System.out.println(dateBefore+" "+dateAfter);
if (dateBefore.getDayOfMonth() > 28) {
dateBefore = dateBefore.minusDays(5);
} else if (dateAfter.getDayOfMonth() > 28) {
dateAfter = dateAfter.minusDays(5);
}
return ChronoUnit.MONTHS.between(dateBefore, dateAfter);
}
The Java API response is mathematically accurate according to the calendar. But you need a similar mechanism, such as rounding decimals, to get the number of months between dates that matches the human perception of the approximate number of months between two dates.
Period period = Period.between(LocalDate.parse("2016-08-31"), LocalDate.parse("2016-11-30"));
long months = period.toTotalMonths();
if (period.getDays() >= 15) {
months++;
}
I have a map of string values which represent down times for different components.
dependencyMap.put ("sut", "14:26:12,14:27:19,00:01:07;15:01:54,15:02:54,00:01:00;15:44:30,15:46:30,00:02:00;16:10:30,16:11:30,00:01:00");
dependencyMap.put ("jms", "14:26:12,14:28:12,00:02:00;15:10:50,15:12:55,00:02:05;15:42:30,15:43:30,00:01:00;16:25:30,16:27:30,00:02:00");
The strings represent the start, end and duration of down times.
(start)14:26:12,(end)14:27:19,(duration)00:01:07
I read the values in, then add them to a list of DependencyDownTime objects which hold the Long values startTime, endTime and duration.
jArray.forEach (dependency ->{
String downTimeValues = knownDowntimesMap.get(dependency);
final String[] downtime = downTimeValues.split (";");
for (final String str : downtime) {
final DependencyDownTime depDownTime = new DependencyDownTime ();
final String[] strings = str.split (",");
if (strings.length == 3) {
final DateFormat dateFormat = new SimpleDateFormat ("HH:mm:ss");
try {
depDownTime.setStartTime(dateFormat.parse (strings[0]).getTime ());
depDownTime.setEndTime (dateFormat.parse (strings[1]).getTime ());
depDownTime.setDuration (dateFormat.parse (strings[2]).getTime ());
downTimes.add (depDownTime);
} catch (final ParseException e) {
//logger.warn (e.getMessage (), e);
}
} else {
//logger.warn ("");
}
}
I then perform simple arithmetic on the values, which calculates the total down time for each component.
// sort the list by start time
Collections.sort(downTimes, Comparator.comparing (DependencyDownTime::getStartTime));
int i = 1;
Long duration = 0L;
for(DependencyDownTime dts: downTimes){
Long curStart = dts.getStartTime ();
Long curEnd = dts.getEndTime();
Long nextStart = downTimes.get(i).getStartTime ();
Long nextEnd = downTimes.get(i).getEndTime ();
if(duration == 0){
duration = dts.getDuration();
}
if(curStart.equals(nextStart) && curEnd < nextEnd){
duration += (nextEnd - curEnd);
}
else if(nextStart > curEnd){
duration += downTimes.get(i).getDuration();
}
else if( curStart < nextStart && curEnd > nextStart){
duration += (nextEnd - curEnd);
}
else if(curEnd == nextStart){
duration += downTimes.get(i).getDuration();
}
i++;
if(i == downTimes.size ()){
componentDTimeMap.put (application, duration);
return;
}
The expected values should be something like 1970-01-01T 00:14:35 .000+0100, a matter of minutes. The actual result is usually extremely high off by a matter of hours in the difference 1969-12-31T 15:13:35 .000+0100
I have 2 questions.
Am I parsing the values correctly?
If my calculations are a little off when adding and subtracting the long values. When I convert the values back to Date format will there be a drastic difference in the expected value?
As explained in your other question, don't mistake those 2 different concepts:
a time of the day: it represents a specific point of a day, such as 10 AM or 14:45:50
a duration: it represents an amount of time, such as "1 hour and 10 minutes" or "2 years, 3 months and 4 days". The duration doesn't tell you when it starts or ends ("1 hour and 10 minutes" relative to what?), it's not attached to a chronology, it doesn't correspond to a specific point in the timeline. It's just the amount of time, by itself.
In your input, you have:
(start)14:26:12,(end)14:27:19,(duration)00:01:07
The start and end represents times of the day, and the duration represents the amount of time. SimpleDateFormat is designed to work with dates and times of the day, but not with durations. Treating the duration as a time of the day might work, but it's a hack as explained in this answer.
Another problem is that when SimpleDateFormat parses only a time, it defaults the day to January 1st 1970 at the JVM default timezone, leading to all the strange results you see. Unfortunately there's no way to avoid that, as java.util.Date works with full timestamps. A better alternative is to use the new date/time API.
As in your other question you're using Java 8, I'm assuming you can also use it here (but if you're using Java <= 7, you can use the ThreeTen Backport, a great backport for Java 8's new date/time classes. The only difference is the package names (in Java 8 is java.time and in ThreeTen Backport (or Android's ThreeTenABP) is org.threeten.bp), but the classes and methods names are the same).
As you're working only with times, there's no need to consider date fields (day/month/year), we can use a LocalTime instead. You can parse the strings directly, because they are in ISO861 compliant format:
LocalTime start = LocalTime.parse("14:26:12");
LocalTime end = LocalTime.parse("14:27:19");
Unfortunately there are no built-in parsers for a duration, so you'll have to parse it manually:
// parse the duration manually
String[] parts = "00:01:07".split(":");
Duration d = Duration
// get hours
.ofHours(Long.parseLong(parts[0]))
// plus minutes
.plusMinutes(Long.parseLong(parts[1]))
// plus seconds
.plusSeconds(Long.parseLong(parts[2]));
Another alternative is to remove the durations from your input (or ignore them) and calculate it using the start and end:
Duration d = Duration.between(start, end);
Both will give you a duration of 1 minute and 7 seconds.
My suggestion is to change the DependencyDownTime to store start and end as LocalTime objects, and the duration as a Duration object. With this, your algorithm would be like this:
Duration total = Duration.ZERO;
for (...) {
LocalTime curStart = ...
LocalTime curEnd = ...
LocalTime nextStart = ...
LocalTime nextEnd = ...
if (total.toMillis() == 0) {
duration = dts.getDuration();
}
if (curStart.equals(nextStart) && curEnd.isBefore(nextEnd)) {
total = total.plus(Duration.between(curEnd, nextEnd));
} else if (nextStart.isAfter(curEnd)) {
total = total.plus(downTimes.get(i).getDuration());
} else if (curStart.isBefore(nextStart) && curEnd.isAfter(nextStart)) {
total = total.plus(Duration.between(curEnd, nextEnd));
} else if (curEnd.equals(nextStart)) {
total = total.plus(downTimes.get(i).getDuration());
}
i++;
if (i == downTimes.size()) {
// assuming you want the duration as a total of milliseconds
componentDTimeMap.put(application, total.toMillis());
return;
}
}
You can either store the Duration object, or the respective value of milliseconds. Don't try to transform it to a Date, because a date is not designed nor supposed to work with durations. You can adapt this code to format a duration if you want (unfortunately there are no native formatters for durations).
Limitations
The code above assumes that all start and end times are in the same day. But if you have start at 23:50 and end at 00:10, should the duration be 20 minutes?
If that's the case, it's a little bit trickier, because LocalTime is not aware of the date (so it considers 23:50 > 00:10 and the duration between them is "minus 23 hours and 40 minutes").
In this case, you could do a trick and assume the dates are all at the current date, but when start is greater than end, it means that end time is in the next day:
LocalTime start = LocalTime.parse("23:50");
LocalTime end = LocalTime.parse("00:10");
// calculate duration
Duration d;
if (start.isAfter(end)) {
// start is after end, it means end is in the next day
// current date
LocalDate now = LocalDate.now();
// start is at the current day
LocalDateTime startDt = now.atTime(start);
// end is at the next day
LocalDateTime endDt = now.plusDays(1).atTime(end);
d = Duration.between(startDt, endDt);
} else {
// both start and end are in the same day
// just calculate the duration in the usual way
d = Duration.between(start, end);
}
In the code above, the result will be a Duration of 20 minutes.
Don't format dates as durations
Here are some examples of why SimpleDateFormat and Date aren't good to handle durations of time.
Suppose I have a duration of 10 seconds. If I try to transform it to a java.util.Date using the value 10 to a date (AKA treating a duration as a date):
// a 10 second duration (10000 milliseconds), treated as a date
Date date = new Date(10 * 1000);
System.out.println(date);
This will get a date that corresponds to "10000 milliseconds after unix epoch (1970-01-01T00:00Z)", which is 1970-01-01T00:00:10Z. But when I print the date object, the toString() method is implicity called (as explained here). And this method converts this millis value to the JVM default timezone.
In the JVM I'm using, the default timezone is America/Sao_Paulo, so the code above outputs:
Wed Dec 31 21:00:10 BRT 1969
Which is not what is expected: the UTC instant 1970-01-01T00:00:10Z corresponds to December 31st 1969 at 9 PM in São Paulo timezone.
This happens because I'm erroneously treating the duration as a date (and the output will be different, depending on the default timezone configured in the JVM).
A java.util.Date can't (must not) be used to work with durations. Actually, now that we have better API's, it should be avoided whenever possible. There are too many problems and design issues with this, just don't use it if you can.
SimpleDateFormat also won't work properly if you handle the durations as dates. In this code:
SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");
Date d = dateFormat.parse("10:00:00");
The input has only time fields (hour, minute and second), so SimpleDateFormat sets the date to January 1st 1970 at the JVM default timezone. If I System.out.println this date, the result will be:
Thu Jan 01 10:00:00 BRT 1970
That's January 1st 1970 at 10 AM in São Paulo timezone, which in UTC is equivalent to 1970-01-01T13:00:00Z - so d.getTime() returns 46800000.
If I change the JVM default timezone to Europe/London, it will create a date that corresponds to January 1st 1970 at 10 AM in London (or UTC 1970-01-01T09:00:00Z) - and d.getTime() now returns 32400000 (because 10 AM in London and 10 AM in São Paulo happened at different instants).
SimpleDateFormat isn't the right tool to work with durations - it isn't even the best tool to work with dates, actually.
I don't really know exactly how to explain this but basically the user is asked how many times, say they say 2. It will ask the user to input a month, day and year in numerical form. Then it will do it again because they said 2. It spits out a date in (Saturday, January 8th, 2014) format for each date they put in. So what I want is:
There were X dates on Sunday
There were X dates on Monday
There were X dates on Tuesday
There were X dates on Wednesday
There were X dates on Thursday
There were X dates on Friday
There were X dates on Saturday
How can I make java recognize the day of week and then add one to it so I can replace X above.
I have variables for each day, for example int saturday. I know I have to do saturday++; somewhere but I don't know where. I tried a switch and case but it doesn't know
case Monday:
because Monday is no where in my code, I used a simple date format.
Does this make sense? Should I post my code? Warning its like 300 lines.
As Pshemo said "In short, I want the user to say how many "events" occurred, pass their dates and print how many of then happened in each day of week"
Try to format your SimpleDateFormat using an E, which will output the day of the week. Than compare that Date as a String with your weekdays, e.g. day.equals("Monday").
Reference to SimpleDateFormat: http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html
The days of the week are int constants in java.util.Calendar. You can find it using:
int dayOfTheWeek = c.get(Calendar.DAY_OF_WEEK);
Here is some example code using the Joda-Time 2.3 library.
The day-of-week is an interpretation based on the time zone. In Joda-Time, a DateTime object actually knows its own time zone, unlike a java.util.Date which seems to have a time zone but does not. Think about whether you want each DateTime object to use its own time zone to determine day-of-week or you way want to convert the objects to a common time zone for comparison.
DateTimeZone timeZone = DateTimeZone.forID( "Europe/Paris" );
java.util.List<DateTime> dateTimes = new java.util.ArrayList<DateTime>();
dateTimes.add( new DateTime( 2014, 1, 2, 3, 4, 5, timeZone ) ); // Thursday
dateTimes.add( new DateTime( 2014, 1, 3, 3, 4, 5, timeZone ) ); // Friday
dateTimes.add( new DateTime( 2014, 1, 9, 3, 4, 5, timeZone ) ); // Thursday
System.out.println( "Date-Time objects…" );
System.out.println( dateTimes );
// Make a list of 7 elements, one element per each day of week.
// Each element stores a count of events occurring on that day of week.
// Using standard ISO 8601 week, Monday first, Sunday last.
java.util.List<Integer> days = new java.util.ArrayList<Integer>( 7 );
for ( int i = 0; i < 7; i++ ) {
days.add( new Integer( 0 ) ); // Initial all counts to zero.
}
for ( DateTime dateTime : dateTimes ) {
int dayOfWeekNumber = dateTime.getDayOfWeek(); // Retrieve day-of-week number, 1-7. Monday is first.
int index = ( dayOfWeekNumber - 1 ); // Index/Zero-based counting, so subtract 1 from ordinal.
Integer oldIntegerCount = days.get( index ); // Retrieve the previous count for this day-of-week.
Integer newIntegerCount = ( oldIntegerCount + 1 ); // Increment old count to new count object.
days.set( index, newIntegerCount ); // Replace old Integer object with freshly incremented Integer object.
}
// Report results.
// Joda-Time does not have a convenient list of days of week to iterate. So the following code is a bit goofy.
// The java.time.* package in Java 8 does have the nice feature of a fancy Enum for days-of-week.
for ( int i = 0; i < days.size(); i++ ) {
LocalDate date = new LocalDate();
date = date.withDayOfWeek( i + 1 ); // Add one to transform index into ordinal.
System.out.println( "There were " + days.get( i ) + " dates on " + date.dayOfWeek().getAsText() );
}
When run…
Date-Time objects…
[2014-01-02T03:04:05.000+01:00, 2014-01-03T03:04:05.000+01:00, 2014-01-09T03:04:05.000+01:00]
There were 0 dates on Monday
There were 0 dates on Tuesday
There were 0 dates on Wednesday
There were 2 dates on Thursday
There were 1 dates on Friday
There were 0 dates on Saturday
There were 0 dates on Sunday