This question already has answers here:
Java Date year calculation is off by year for two days
(5 answers)
Closed 6 years ago.
This is actually a duplicate of Y returns 2012 while y returns 2011 in SimpleDateFormat I'll take the ding for duplicate on this one not the one listed below. I read the answer on that and I still think there is an error there. The first day of the week in my system is Sunday so by the description from the java.doc This should have been the 53rd week of 2017 not the 1st week of 2018, if I was going to get an error January 1st through the 6th should have returned 2017.
This is not a duplicate of Calendar return incorrect date, the calendar is working fine. see additional information below I was trying to simplify my code for display purposes at EOD as I was hopeing to get out of the door
When using SimpleDateFormat.Format to convert a Calendar date of 12/31/2017 (2017,11,31,0,0) (Sunday first day of the week, last week of the year) SimpleDateFormat returns 12/31/2018. I have tried this with java 6,7,8 and get the same results, I tried it on two different versions of eclipse I tried it on another developers computer all this the same result. This is pulled from my actual junit code.
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Date;
public class SimpleDateTest2 {
public static void main(String[] args) {
// TODO Auto-generated method stub
Calendar t_calendar = Calendar.getInstance();
Calendar m_calc_calendar = Calendar.getInstance();
int rc=0;
int testDays=20;
Date rDate;
SimpleDateFormat ssaDateFormat= new SimpleDateFormat("YYMMdd");
SimpleDateFormat logDateFormat= new SimpleDateFormat("E MM/dd/YYYY");
ArrayList<Date> testDates = new ArrayList<Date>();
t_calendar.set(2017,11,20,0,0); // start date
//t_calendar.set(2018,11,20,0,0); // start date
t_calendar.setLenient(false);
// builds 2600 dates for test run reason for Date (24 bytes) vs Calendar (423 bytes)
for(int days=0; days<testDays;days++){
t_calendar.add(Calendar.DATE, 1);
testDates.add(t_calendar.getTime());
}
for(Date testDate: testDates){
String test = testDate.toString();
System.out.println("toString: " + test);
t_calendar.setTimeInMillis(testDate.getTime());
test = ssaDateFormat.format(t_calendar.getTime());
System.out.println(" Cal.year " + t_calendar.get(Calendar.YEAR) + " Cal.month " + t_calendar.get(Calendar.MONTH) + " Cal.day " + t_calendar.get(Calendar.DATE) + " Cal.week " + t_calendar.get(Calendar.WEEK_OF_YEAR) );
System.out.println("ssa conversion: " + test);
test = logDateFormat.format(t_calendar.getTime());
System.out.println("log conversion: " + test);
System.out.println(t_calendar.toString());
System.out.println("");
// call to method under test
//rDate=rsl.calculateSSATransDate(ssaDateFormat.format(testDate),new BigDecimal(1.0));
// result validation.
}
}
Test Results
toString: Sat Dec 29 00:00:53 PST 2018 <-- input date
Cal.year 2018 Cal.month 11 Cal.day 29 Cal.week 52
ssa conversion: 181229
log conversion: Sat 12/29/2018 <-- result is good
java.util.GregorianCalendar[time=1546070453716,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=11,WEEK_OF_YEAR=52,WEEK_OF_MONTH=5,DAY_OF_MONTH=29,DAY_OF_YEAR=363,DAY_OF_WEEK=7,DAY_OF_WEEK_IN_MONTH=5,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=53,MILLISECOND=716,ZONE_OFFSET=-28800000,DST_OFFSET=0]
toString: Sun Dec 30 00:00:53 PST 2018 <-- Input date
Cal.year 2018 Cal.month 11 Cal.day 30 Cal.week 1
ssa conversion: 191230 <-- Result is bad
log conversion: Sun 12/30/2019
java.util.GregorianCalendar[time=1546156853716,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=6,DAY_OF_MONTH=30,DAY_OF_YEAR=364,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=5,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=53,MILLISECOND=716,ZONE_OFFSET=-28800000,DST_OFFSET=0]
toString: Mon Dec 31 00:00:53 PST 2018 <-- Input date
Cal.year 2018 Cal.month 11 Cal.day 31 Cal.week 1
ssa conversion: 191231
log conversion: Mon 12/31/2019 <-- Result is bad
java.util.GregorianCalendar[time=1546243253716,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=6,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=2,DAY_OF_WEEK_IN_MONTH=5,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=53,MILLISECOND=716,ZONE_OFFSET=-28800000,DST_OFFSET=0]
toString: Tue Jan 01 00:00:53 PST 2019 <-- input date
Cal.year 2019 Cal.month 0 Cal.day 1 Cal.week 1
ssa conversion: 190101
log conversion: Tue 01/01/2019 <-- Result is good
java.util.GregorianCalendar[time=1546329653716,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2019,MONTH=0,WEEK_OF_YEAR=1,WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=1,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=53,MILLISECOND=716,ZONE_OFFSET=-28800000,DST_OFFSET=0]
As I look forward to the dates I see the issue repeat in this pattern
- in 2018 12/30 (Sun) and 12/31(Mon) in 2018,
- in 2019 I have issues with 12/29(Sun), 12/30(Mon) and 12/31 (Tues)
- in 2020 12/27(Sun), 12/28(Mon), 12/29(Tues), 12/30 (Wed) 12/31(Thurs)
- in 2021 12/26(Sun) - 12/31(Fri)
- 2022 is correct
- 2023 restarts the loop.
It has to do with the last incomplete week of the year but I haven't been able to solve the issue.
Months are 0 based i.e. January is 0 December is 11
try
c.set(2017, 11, 31, 0, 0);
I want to precisely calculate the time one week from a given date, but the output I get back is one hour early.
code:
long DURATION = 7 * 24 * 60 * 60 * 1000;
System.out.println(" now: " + new Date(System.currentTimeMillis()));
System.out.println("next week: " + new Date(System.currentTimeMillis() + DURATION));
output:
now: Wed Sep 16 09:52:36 IRDT 2015
next week: Wed Sep 23 08:52:36 IRST 2015
How can I calculate this correctly?
Never, ever rely on millisecond arithmetic, there are too many rules and gotchas to make it of any worth (even over a small span of time), instead use a dedicated library, like Java 8's Time API, JodaTime or even Calendar
Java 8
LocalDateTime now = LocalDateTime.now();
LocalDateTime then = now.plusDays(7);
System.out.println(now);
System.out.println(then);
Which outputs
2015-09-16T15:34:14.771
2015-09-23T15:34:14.771
JodaTime
LocalDateTime now = LocalDateTime.now();
LocalDateTime then = now.plusDays(7);
System.out.println(now);
System.out.println(then);
Which outputs
2015-09-16T15:35:19.954
2015-09-23T15:35:19.954
Calendar
When you can't use Java 8 or JodaTime
Calendar cal = Calendar.getInstance();
Date now = cal.getTime();
cal.add(Calendar.DATE, 7);
Date then = cal.getTime();
System.out.println(now);
System.out.println(then);
Which outputs
Wed Sep 16 15:36:39 EST 2015
Wed Sep 23 15:36:39 EST 2015
nb: The "problem" you seem to be having, isn't a problem at all, but simply the fact that over the period, your time zone seems to have entered/exited day light savings, so Date is displaying the time, with it's correct offset
Try this
Calendar cal = Calendar.getInstance();
System.out.println(cal.getTime());
cal.add(Calendar.DAY_OF_MONTH, 7);
System.out.println(cal.getTime());
The difference is because of the different timezone. IRDT is +0430 and IRST is +0330
To overcome this issue you can use the JodaTime.
LocalDateTime now = LocalDateTime.now();
LocalDateTime nextweek = now.plusDays(7);
System.out.println(now);
System.out.println(nextweek);
As other said. It would be better to use Calendar or JodaTime library. But the question is why you were not getting the desired result. It was because currentTimeMillis() calculates time between "computer time" and coordinated universal time (UTC). Now consider following case.
long DURATION = 7 * 24 * 60 * 60 * 1000;
Date now = new Date();
Date nextWeek = new Date(now.getTime() + DURATION);
System.out.println(" now: " + now);
System.out.println("next week: " + nextWeek);
here Date.getTime() calculate time from 00:00:00 GMT every time and then when converted to string will give time for your local time zone.
Edit :
I was wrong. The reason is as simon said.
The actual "why" is that IRDT (Iran Daylight Time) ends on September
22nd. That's why the first date (September 16th) in the OP's post is
displayed as IRDT and the second date (September 23rd) is displayed as
IRST. Because IRST (Iran Standard Time) is one hour earlier than IRDT
the time displayed is 08:52:36 instead of 09:52:36.
From the below java code I'm getting a month First & last dateTimestamp, but here i need last dateTimestamp as - "Mon Aug 31 23:59:59 IST 2015" instead of - "Mon Aug 31 00:00:00 IST 2015"?
Calendar cal = Calendar.getInstance();
int year = 2015;
int month = 07;
cal.set(cal.DATE,1);
cal.set(cal.YEAR,year);
cal.set(cal.MONTH, month);
String firstDate = (cal.getActualMinimum(cal.DATE) + "/" + (month+1) + "/" +year);
System.out.println("firstDate-->"+"\t"+firstDate);
String lastDate = (cal.getActualMaximum(cal.DATE) + "/" + (month+1) + "/" +year);
System.out.println("lastDate-->"+"\t"+lastDate);
DateFormat firstFormat = new SimpleDateFormat("dd/MM/yyyy");
Date beginDate = firstFormat.parse(firstDate);
System.out.println("BeginDate Timestamp"+ "\t" + beginDate);
DateFormat secoundFormat = new SimpleDateFormat("dd/MM/yyyy");
Date endDate = secoundFormat.parse(lastDate);
System.out.println("endDate Timestamp"+ "\t" + endDate);
Output:->
firstDate--> 1/8/2015
lastDate--> 31/8/2015
BeginDate Timestamp Sat Aug 01 00:00:00 IST 2015
endDate Timestamp Mon Aug 31 00:00:00 IST 2015
Please help me if we have any solution.
If I understand your question, it looks as if you want to pass a year and month into a method, and get back the last day of the passed month.
I would suggest consider (in this order):
which jdk you use
configuration of calendar
configuration of timezone (maybe)
using jodatime
As of 1.8 many JodaTime-like features have been added to the jdk- e.g. see https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html (If you arent using 1.8 you can use the joda lib, assuming your organization allows it)
Calendar.getInstance() gives a default TimeZone and a default Locale, which means the definitions of the running JVM. You may or may not need to consider this and implement more than just getInstance(). See API javadoc.
Assuming a Gregeorian Calendar (hey, you could be Bahaian and have 19 months in the year ...) , here is one partial implementation using JDK 1.7, JodaTime jar 2.2, validation-1.0.0.GA jar:
#Test
public void testDate() {
final String dateStringOfFirstDay = "1.7.2015";
final Date lastDayOfMonth = getLastDayOfMonth(dateStringOfFirstDay);
Assert.assertNotNull(lastDayOfMonth);
//more assertions ...
}
private Date getLastDayOfMonth(#NotNull String dateStringOfFirstDay) {
//further validation here necessary according to required date format
DateTime dt = DateTime.parse(dateStringOfFirstDay);
return dt.dayOfMonth().withMaximumValue().toDate();
}
The defintion of DateFormat/DateTimeFormat and further result assertions is left up to you.
Best of luck!
Guys I got a solution for my question!!!
I think it will help u too...
Calendar calendar = Calendar.getInstance();
int year=2015;
int month=7;
int date=31;
int hourOfDay=23;
int minute=59;
int second=59;
int milliSecond=999;
calendar.set(year, month, date, hourOfDay, minute, second);
calendar.set(calendar.MILLISECOND, milliSecond);
System.out.println("Time from Calendar: "+calendar.getTime());
long timeInMilliSeconds=calendar.getTimeInMillis();
System.out.println("timeInMilliSeconds from calendar: "+timeInMilliSeconds);
Timestamp timestamp=new Timestamp(timeInMilliSeconds);
System.out.println(timestamp);
The above program gives the last date last timestamp in a selected month.
getTimeInMillis() takes the time from Jan 01, 1970 to current time in Milliseconds.
Using those milliseconds i'm getting the Timestamp.
Thank you for your help guys!!!
OutPut:->
Time from Calendar: Mon Aug 31 23:59:59 IST 2015
timeInMilliSeconds from calendar: 1441045799999
2015-08-31 23:59:59.999
i'm having a problem while converting Timestamp objects to joda's LocalTime.
See example below:
public static void main(String[] args) {
Timestamp t = Timestamp.valueOf("1111-11-11 00:00:00");
System.out.println(t); //-- prints '1111-11-11 00:00:00.0'
System.out.println(new LocalDate(t)); //-- prints '1111-11-17'
Calendar calendar = Calendar.getInstance();
calendar.setTime(t);
System.out.println(LocalDate.fromCalendarFields(calendar)); //-- prints '1111-11-11'
}
I could not determine why 'new LocalDate(t)' results in '1111-11-17'. Can anyone help me on that?
I notice this "problem" while using joda-time-hibernate to populate my bean's property of type LocalDate.
This indeed has to do with the different types of calendars. java.sql.Timestamp, like java.util.Date, don't have any calendar information, as they are stored solely as a number, the number of milliseconds since 1970, with the implied assumption that there was a jump between October 4 and October 15 1582, when the Gregorian calendar was officially adopted, replacing the old Julian calendar. So, you can't possibly have a Date (or Timestamp) object representing October 7, 1582. If you try to create such a date, you'll automatically end up 10 days later. For example:
Calendar c = Calendar.getInstance();
c.setTimeZone(TimeZone.getTimeZone("UTC"));
c.set(1582, Calendar.OCTOBER, 7, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
d = c.getTime();
System.out.println("Date: " + d);
// Prints:
// Date: Sun Oct 17 00:00:00 GMT 1582
In other words, Date objects have an implied Julian+Gregorian chronology, automatically switching between those two.
JodaTime is a bit smarter, it supports several Chronologies, including a continuing Julian, a proleptic Gregorian, a mixed Julian+Gregorian, and a standard ISO Chronology which is almost identical to the Gregorian one. If you read the JavaDoc of the LocalDate.fromCalendarFields method, you'll see that it mentions that:
This factory method ignores the type of the calendar and always creates a LocalDate with ISO chronology.
The mixed Julian+Gregorian chronology behaves like the implicit Java dates, with an automatic switch between the two different calendars. The pure chronologies assume that their calendar system is forever in use, so for example it assumes that the Gregorian calendar has been used since the start of time.
Let's see how each Chronology treats the 1111-11-11 date:
Calendar c = Calendar.getInstance();
c.setTimeZone(TimeZone.getTimeZone("UTC"));
c.set(1111, Calendar.NOVEMBER, 11, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
Date d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
Ends up as:
Date: Sat Nov 11 00:00:00 GMT 1111 (-27079747200000 milliseconds)
ISO: 1111-11-18T00:00:00.000Z
Julian+Gregorian: 1111-11-11T00:00:00.000Z
Julian: 1111-11-11T00:00:00.000Z
Gregorian: 1111-11-18T00:00:00.000Z
As you can see, the two modern chronologies (ISO and Gregorian) report the correct date if they would have been in use since from the start, while the two that use the Julian calendar report the date as it was known back then, although in hindsight we know it to be off by 7 days compared to the true equinox date.
Let's see what happened around the switch:
c.set(1582, Calendar.OCTOBER, 15, 0, 0, 0);
d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
ends up as:
Date: Fri Oct 15 00:00:00 GMT 1582 (-12219292800000 milliseconds)
ISO: 1582-10-15T00:00:00.000Z
Julian+Gregorian: 1582-10-15T00:00:00.000Z
Julian: 1582-10-05T00:00:00.000Z
Gregorian: 1582-10-15T00:00:00.000Z
So the only one that's left behind is the Julian calendar. That was a valid date in all the countries that didn't accept the Gregorian calendar yet, which back then was a lot of countries. Greece made the switch in 1923...
One millisecond before that, the date was:
c.add(Calendar.MILLISECOND, -1);
d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
Meaning:
Date: Thu Oct 04 23:59:59 GMT 1582 (-12219292800001 milliseconds)
ISO: 1582-10-14T23:59:59.999Z
Julian+Gregorian: 1582-10-04T23:59:59.999Z
Julian: 1582-10-04T23:59:59.999Z
Gregorian: 1582-10-14T23:59:59.999Z
The ISO and Gregorian chronologies report a date that didn't actually exist in the Gregorian calendar, since there was no Gregorian calendar before October 15, yet this date is valid in an extended, proleptic Gregorian calendar. It's like finding a BCE date inscribed on a BCE monument... Nobody knew that they were before Christ before Christ was even born.
So, the root of the problem is that a date string is ambiguous, since you don't know in which calendar you're measuring. Is the year 5772 a year in the future, or is it the current Hebrew year? Java assumes a mixed Julian+Gregorian calendar. JodaTime provides extensive support for different calendars, and by default it assumes the ISO8601 chronology. Your date is automatically converted from the Julian calendar in use in 1111 to the ISO chronology that we currently use. If you want your JodaTime-enhanced timestamps to use the same chronology as the java.sql.Timestamp class, then explicitly select the GJChronology when constructing JodaTime objects.
The reason this is happening for dates several centuries in the past has to do with the (worldwide) switch to the Gregorian Calendar from the Julian Calendar. Basically, as countries implemented the new calendar system in a piecemeal fashion, they would lose days or weeks (and in some cases, months) in the process. In Spain, for example, 4 October 1582 in the Julian calendar was followed immediately by 15 October 1582 in the Gregorian calendar. Wikipedia has a decent discussion of the topic.
As long as your application does not deal with dates too far in the past, you won't have to deal with discrepancies related to this. As you mentioned in your comment, System.out.println(new LocalDate(Timestamp.valueOf("1999-11-11 00:00:00"))) correctly outputted 1999-11-11. If you need to work with these older dates, I'd suggest looking into an alternative date for the Julian calendar.
(As an aside, I'd be curious to see what would happen if you asked for the local date, in Spain, of 5 October 1582 ... a day which never happened.)