Develop Reference

Calling getTime changes Calendar value

I'm trying to get the sunday of the same week as a given date.
During this I ran into this problem:
Calendar calendar = Calendar.getInstance(Locale.GERMANY);
calendar.set(2017, 11, 11);
calendar.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
System.out.println(calendar.getTime().toString());
results in "Sun Jan 07 11:18:42 CET 2018"
but
Calendar calendar2 = Calendar.getInstance(Locale.GERMANY);
calendar2.set(2017, 11, 11);
calendar2.getTime();
calendar2.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
System.out.println(calendar2.getTime().toString());
gives me the correct Date "Sun Dec 17 11:18:42 CET 2017"
Can someone explain why the first exmple is behaving this way? Is this really intended?
Thanks

Basically, the Calendar API is horrible, and should be avoided. It's not documented terribly clearly, but I think I see where it's going, and it's behaving as intended in this situation. By that I mean it's following the intention of the API authors, not the intention of you or anyone reading your code...
From the documentation:
The calendar field values can be set by calling the set methods. Any field values set in a Calendar will not be interpreted until it needs to calculate its time value (milliseconds from the Epoch) or values of the calendar fields. Calling the get, getTimeInMillis, getTime, add and roll involves such calculation.
And then:
When computing a date and time from the calendar fields, there may be insufficient information for the computation (such as only year and month with no day of month), or there may be inconsistent information (such as Tuesday, July 15, 1996 (Gregorian) -- July 15, 1996 is actually a Monday). Calendar will resolve calendar field values to determine the date and time in the following way.
If there is any conflict in calendar field values, Calendar gives priorities to calendar fields that have been set more recently. The following are the default combinations of the calendar fields. The most recent combination, as determined by the most recently set single field, will be used.
For the date fields:
YEAR + MONTH + DAY_OF_MONTH
YEAR + MONTH + WEEK_OF_MONTH + DAY_OF_WEEK
YEAR + MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK
YEAR + DAY_OF_YEAR
YEAR + DAY_OF_WEEK + WEEK_OF_YEAR
In the first example, the fact that the last field set was "day of week" means it will then use the YEAR + MONTH + WEEK_OF_MONTH + DAY_OF_WEEK calculation (I think). The year and month have been set to December 2017, but the week-of-month is the current week-of-month, which is the week 5 of January 2018... so when you then say to set the day of week to Sunday, it's finding the Sunday in the "week 5" of December 2017. December only had 4 weeks, so it's effectively rolling it forward... I think. It's all messy and you shouldn't have to think about that, basically.
In the second example, calling getTime() "locks in" the year/month/day you've specified, and computes the other fields. When you set the day of week, that's then adjusting it within the existing computed fields.
Basically, avoid this API as far as you possibly can. Use java.time, which is a far cleaner date/time API.

As Jon Skeet said, avoid Calendar. For your case it is truly horrible, and it’s poorly designed in general. Instead do
WeekFields weekFieldsForLocale = WeekFields.of(Locale.GERMANY);
// To find out which number Sunday has in the locale,
// grab any Sunday and get its weekFieldsForLocale.dayOfWeek()
int dayNumberOfSundayInLocale = LocalDate.now()
.with(TemporalAdjusters.nextOrSame(DayOfWeek.SUNDAY))
.get(weekFieldsForLocale.dayOfWeek());
LocalDate date = LocalDate.of(2017, Month.DECEMBER, 11);
LocalDate sunday
= date.with(weekFieldsForLocale.dayOfWeek(), dayNumberOfSundayInLocale);
System.out.println(sunday);
This prints the expected date
2017-12-17
As others have already mentioned, the solution is to use java.time, the modern Java date and time API. Also generally it is so much nicer to work with. One nice feature is the LocalDate class that I am using. It is a date without time of day, which seems to match your requirements more precisely that Calendar did.
If the above looks complicated, it’s because, as I think you are aware, “Sunday of the same week” means different things in different locales. In the international standard that Germany follows, weeks begin on Monday, so Sunday is the last day of the week. In the American standard, for example, Sunday os the first day of the week. WeekFields.dayOfWeek() numbers the days of the week from 1 to 7, so when we want to set the day to Sunday, we first need to find out which number Sunday has got in this numbering (7 in Germany, 1 in the US). So for any Sunday, get its weekFieldsForLocale.dayOfWeek() value and later use this for setting the day of week to Sunday. The reason why this is necessary is that the with() method is so general and therefore has been designed to accept only numeric values; we can’t just pass it a DayOfWeek object.
If I substitute Locale.US into the code, I get 2017-12-10, which is the correct Sunday for a calendar where Sunday is the first day of the week. If you are sure your only want your code to work for Germany, you may of course just hardcode a 7 (please make it a constant with a very explanatory name).
Link: Oracle Tutorial Date Time explaining how to use java.time. There are other resources on the net (just avoid the outdated placed that suggest java.util.Calendar :-)

Date picker first and last day of previous

Could someone please help me in finding from datepicker first and last day of previous month.
Achieved to pickup current date and 1st of current month, with following:
// Choose today's date
String today = LocalDate.now().format(DateTimeFormatter.ofPattern("dd/MM-YYYY"));
driver.findElement(By.xpath("//*[#id=\"viewPeriodStart\"]")).clear();
driver.findElement(By.xpath("//*[#id=\"viewPeriodStart\"]")).sendKeys(today);
//Choose first of a month
String firstDayinMOnth = LocalDate.now().format(DateTimeFormatter.ofPattern("01/MM-YYYY"));
driver.findElement(By.xpath("//*[#id=\"viewPeriodEnd\"]")).clear();
driver.findElement(By.xpath("//*[#id=\"viewPeriodEnd\"]")).sendKeys(firstDayinMOnth + Keys.ENTER);
Thread.sleep(8000);
driver.findElement(By.xpath("//*[#id=\"calenderShowHide\"]/div/input[3]")).click();
But have no idea how to create 1st and last of previous month.
Thank you in advance

Solved, after a bit of Googling & checking:
String lastDay = LocalDate.now().withDayOfMonth(1).minusDays(1).format(DateTimeFormatter.ofPattern("dd/MM-YYYY"));
String firstDay = LocalDate.now().withDayOfMonth(1).minusDays(1).withDayOfMonth(1).format(DateTimeFormatter.ofPattern("dd/MM-YYYY"));

These points were not what you asked, but I believe they are still helpful suggestions for you.
Consider half-open intervals.
Read LocalDate.now() only once for consistency.
Give your desired time zone.
Don’t use uppercase YYYY in your format pattern string.
Half-open: It’s natural to think of the days of a month as being from the first of the month to the last day of the month inclusive. However, a standard handling would go from the first of the month inclusive to the first of the next month exclusive. It’s still the same days, only a different representation. Particularly when you handle successive months this gives simplicity and prevents errors: when you have the first of this month, you don’t also need the last of the previous month. And there’s no way you could make a gap between the two periods by mistake.
Read today’s date only once. If your code happens to run across midnight, you may accept that you cannot control whether it uses the date from before 0:00 or the date after, but you want to make sure it doesn’t use both for the different date calculations, or you risk inconsistent dates, like all the dates belonging to the same month rather than last month and this month.
Give a time zone: It is never the same date in all time zones on Earth. So a time zone is needed for determining today’s date or just current month. Make that explicit. Even if you want ZoneId.systemDefault(), write that to force yourself into making a conscious decision and to tell the reader that you have done so.
LocalDate today = LocalDate.now(ZoneId.of("Europe/Belgrade"));
LocalDate firstDayOfCurrentMonth = today.withDayOfMonth(1);
LocalDate lastDayOfCurrentMonth = today.with(TemporalAdjusters.lastDayOfMonth());
YearMonth lastMonth = YearMonth.of(today.getYear(), today.getMonth())
.minusMonths(1);
LocalDate firstDayOfLastMonth = lastMonth.atDay(1);
LocalDate lastDayOfLastMonth = lastMonth.atEndOfMonth();
A YearMonth is a month in the calendar like April 1940 or February 2018. A year and a month. I am deliberately being a bit inconsistent in the code. In production code you would probably want to handle either this and last month through YearMonth objects or none of them. But I am showing you both options so you can make your pick. Use YearMonth.now(ZoneId) if you want current month.
Final point: YYYY in the format pattern string. Here’s a correct version of your formatter:
DateTimeFormatter dateFormatter = DateTimeFormatter.ofPattern("dd/MM-uuuu");
If instead of today I run my code next January and use a formatter with uppercase YYYY, I get the previous month as 01/12-2018 through 31/12-2019. It should have been 31/12-2018, but that date belongs to week 1 of 2019, which is what YYYY gives you. Instead use uuuu or lowercase yyyy.

Why does converting Java Dates before 1582 to LocalDate with Instant give a different date?

Consider this code:
Date date = new SimpleDateFormat("MMddyyyy").parse("01011500");
LocalDate localDateRight = LocalDate.parse(formatter.format(date), dateFormatter);
LocalDate localDateWrong = LocalDateTime.ofInstant(date.toInstant(), ZoneId.systemDefault()).toLocalDate();
System.out.println(date); // Wed Jan 01 00:00:00 EST 1500
System.out.println(localDateRight); // 1500-01-01
System.out.println(localDateWrong); // 1500-01-10
I know that 1582 is the cutoff between the Julian and Gregorian calendars. What I don't know is why this happens, or how to adjust for it.
Here's what I've figured out so far:
The date Object has a BaseCalender set to JulianCalendar
date.toInstant() just returns Instant.ofEpochMilli(getTime())
date.getTime() returns -14830974000000
-14830974000000 is Wed, 10 Jan 1500 05:00:00 GMT Gregorian
So it seems like either the millis returned by getTime() is wrong (unlikely) or just different than I expect and I need to account for the difference.

LocalDate handles the proleptic gregorian calendar only. From its javadoc:
The ISO-8601 calendar system is the modern civil calendar system used
today in most of the world. It is equivalent to the proleptic
Gregorian calendar system, in which today's rules for leap years are
applied for all time. For most applications written today, the
ISO-8601 rules are entirely suitable. However, any application that
makes use of historical dates, and requires them to be accurate will
find the ISO-8601 approach unsuitable.
In contrast, the old java.util.GregorianCalendar class (which is indirectly also used in toString()-output of java.util.Date) uses a configurable gregorian cut-off defaulting to 1582-10-15 as separation date between julian and gregorian calendar rules.
So LocalDate is not useable for any kind of historical dates.
But bear in mind that even java.util.GregorianCalendar often fails even when configured with correct region-dependent cut-off date. For example UK started the year on March 25th before 1752. And there are many more historical deviations in many countries. Outside of Europe even the julian calendar is not useable before introduction of gregorian calendar (or best useable only from a colonialist perspective).
UPDATE due to questions in comment:
To explain the value -14830974000000 let's consider following code and its output:
SimpleDateFormat format = new SimpleDateFormat("MMddyyyy", Locale.US);
format.setTimeZone(TimeZone.getTimeZone("America/New_York"));
Date d = format.parse("01011500");
long t1500 = d.getTime();
long tCutOver = format.parse("10151582").getTime();
System.out.println(t1500); // -14830974000000
System.out.println(tCutOver); // default gregorian cut off day in "epoch millis"
System.out.println((tCutOver - t1500) / 1000); // output: 2611699200 = 30228 * 86400
It should be noted that the value -12219292800000L mentioned in your earlier comment is different by 5 hours from tCutOver due to timezone offset difference between America/New_York and UTC. So in timezone EST (America/New_York) we have exactly 30228 days difference. For the timespan in question we apply the rules of julian calendar that is every fourth year is a leap year.
Between 1500 and 1582 we have 82 * 365 days + 21 leap days. Then we have also to add 273 days between 1582-01-01 and 1582-10-01, finally 4 days until cut-over (remember 4th of Oct is followed by 15th of Oct). At total: 82 * 365 + 21 + 273 + 4 = 30228 (what was to be proved).
Please explain to me why you have expected a value different from -14830974000000 ms. It looks correct for me since it handles the timezone offset of your system, the julian calendar rules before 1582 and the jump from 4th of Oct 1582 to cut-over date 1582-10-15. So for me your question "how do I tell the date object to return the ms to the correct Gregorian date?" is already answered - no correction needed. Keep in mind that this complex stuff is a pretty long time in production use and can be expected to work correctly after so many years.
If you really want to use JSR-310 for that stuff I repeat that there is no support for gregorian cut-over date. The best thing is that you might do your own work-around.
For example you might consider the external library Threeten-Extra which contains a proleptic julian calendar since release 0.9. But it will still be your effort to handle the cut-over between old julian calendar and new gregorian calendar. (And don't expect such libraries to be capable of handling REAL historic dates due to many other reasons like new year start etc.)
Update in year 2017: Another more powerful option would be using HistoricCalendar of my library Time4J which handles much more than just julian/gregorian-cutover.

why Date object returns wrong day?

I am doing this..
String dateString = "12 Nov 2011 12:00"
DateFormat formatter = new SimpleDateFormat("dd MMM yyyy HH:mm");
Date date = formatter.parse(dateString);
System.out.println(date.getDay());
this prints out day as 3 ? why is this happening ? how can I print the correct day?

Please read the documentation it is worth learning by that.
date.getDay() prints the day of the week. It should display 6 as that is a saturday, not sure how you got 3 as the result.

date.getDay() returns the day of the week as a zero-indexed numeric. In this case it should be Saturday (6).
Your result of Wednesday (3) suggests you are using a variation of the provided code and perhaps forgotten that the month is zero-indexed. e.g.
Date date = new Date(2011, 11, 12, 24, 0, 0); // month is now December, and time ticks over to Wednesday 13th
System.out.println(date.getDay()); // this would produce 3
I believe you want date.getDate().
If you are looking for a String representation of the day, take a look at this example:
http://www.java-examples.com/formatting-day-week-using-simpledateformat
Even better, check out the Joda-Time library, it is much more intuitive than the classes provided in the Java SDK. A future version of Java may even adopt a new date framework similar to Joda-Time (JSR-310)

The code you showed should print 6, as this date is a Saturday. On my computer that happens. without further information I cannot deduce more. Is this the complete code you execute? You could print the value of date.toString(), that would possibly give some more information.

Android: Gregorian Calendar issue

I am getting confuse with using Gregorian.
I am using GregorianCalendar to get the current date and setting the future date.
The current month : it prints me the month as 8 rather 9 where 9 is my expected month.
The current year : it prints me the year in 2011 which is correct.
What is going wrong.
The code I use is GregorianCalender.getInstance(); to get the current date.

Using the jdk's calendar is a little confusing and you'll have to write a lot of code. Instead try a library called joda -
http://joda-time.sourceforge.net/