We Keep Coding

Need Calendar Instance only date (not time) and compare with date String in Kotlin as it lags

I need only date from Calendar Instance not the time. Whenever i used calendar object it returns the date with time.
val calendar = Calendar.getInstance()
calendar.time. // Mon Nov 09 11:41:29 GMT 2020
I change this by using SimpleDateFormat
SimpleDateFormat("dd/MM/yyyy").format(date)
09/09/2020
I am creating calendar so i have huge amount of data in list. I am adding data at specific date. So I am comparing dates with string date. My string date Format is look like this :-
20/05/2020
So there is too much performance issue like lagging the view. So is there any thing which i can use to avoid all this thing.
val calendarModel = dataList?.find {
SimpleDateFormat("dd/MM/yyyy").format(it.date) == item
}

Calendar#getTime returns a java.util.Date object representing this Calendar's time value which is a millisecond value that is an offset from the Epoch, January 1, 1970 00:00:00.000 GMT.
Thus, java.util.Date does not represent a real date or time or date-time object. When you print this millisecond value, your JVM calculates the date and time in its time-zone and when you print its object, you get what java.util.Date#toString returns. From this explanation, you must have already understood that this millisecond value will be the same irrespective of the timezone as it is not a timezone based value; rather, it is fakely represented by java.util.Date#toString as a timezone based value. Just to demonstrate what I have just said, look at the output of the following program:
import java.util.Date;
import java.util.TimeZone;
public class Main {
public static void main(String[] args) {
Date date = new Date();
System.out.println("Asia/Calcutta:");
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Calcutta"));
System.out.println(date.getTime());
System.out.println(date);
System.out.println("\nEurope/London:");
TimeZone.setDefault(TimeZone.getTimeZone("Europe/London"));
System.out.println(date.getTime());
System.out.println(date);
System.out.println("\nAfrica/Johannesburg:");
TimeZone.setDefault(TimeZone.getTimeZone("Africa/Johannesburg"));
System.out.println(date.getTime());
System.out.println(date);
System.out.println("\nAmerica/New_York:");
TimeZone.setDefault(TimeZone.getTimeZone("America/New_York"));
System.out.println(date.getTime());
System.out.println(date);
}
}
Output:
Asia/Calcutta:
1604747702688
Sat Nov 07 16:45:02 IST 2020
Europe/London:
1604747702688
Sat Nov 07 11:15:02 GMT 2020
Africa/Johannesburg:
1604747702688
Sat Nov 07 13:15:02 SAST 2020
America/New_York:
1604747702688
Sat Nov 07 06:15:02 EST 2020
The modern date-time API has real date-time classes. Given below is an overview of these classes:
As you can find in this table, there is a class, LocalDate which represents just date (consisting of a year, month, and day). Given below is a quick demo of the modern java.time API:
import java.time.LocalDate;
import java.time.Month;
import java.time.ZoneId;
import java.time.ZoneOffset;
public class Main {
public static void main(String[] args) {
// A date with the given year, month and day-of-month
LocalDate date = LocalDate.of(2010, Month.NOVEMBER, 7);
System.out.println(date);
// Today (in the JVM's timezone)
LocalDate today = LocalDate.now(); // Same as LocalDate.now(ZoneId.systemDefault())
System.out.println(today);
// Today at UTC
LocalDate todayAtUTC = LocalDate.now(ZoneOffset.UTC);
System.out.println(todayAtUTC);
// Today in India
LocalDate todayInIndia = LocalDate.now(ZoneId.of("Asia/Calcutta"));
System.out.println(todayAtUTC);
}
}
Output:
2010-11-07
2020-11-07
2020-11-07
2020-11-07
Learn more about the modern date-time API at Trail: Date Time.
Recommendation: The date-time API of java.util and their formatting API, SimpleDateFormat are outdated and error-prone. I suggest you should stop using them completely and switch to the modern date-time API.
If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.

Converting Date to LocalDate returning strange results around 200AD

I'm getting inconsistent results when converting Dates to LocalDates, around the year 200. Using the following code to do the conversion:
private LocalDate toLocalDate(Date localDate)
{
return LocalDateTime.ofInstant(localDate.toInstant(), ZoneId.systemDefault()).toLocalDate();
}
My ZoneId.systemDefault() is Africa/Harare, which matches the CAT used in the test. The test case I run is
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy", Locale.US);
String dateString = "Tue Jan 01 00:00:00 CAT 200";
String dateString2 = "Tue Jan 01 00:00:00 CAT 201";
String dateString3 = "Wed Dec 31 00:00:00 CAT 200";
System.out.println(toLocalDate(simpleDateFormat.parse(dateString)));
System.out.println(toLocalDate(simpleDateFormat.parse(dateString2)));
System.out.println(toLocalDate(simpleDateFormat.parse(dateString3)));
My expected output for this would be
0200-01-01
0201-01-01
0200-12-31
Or, if not that, at least consistently incorrect values. The actual results are
0199-12-31
0201-01-01
0200-12-31
So it seems that the first one is being rolled back slightly, possibly the two hours corresponding to the CAT timezone? But why does this only happen on the one case? Doing the same experiment with the year 2000 does not produce the same error.

Stephen has provided an explanation in the comment. Basically, java.util.Date uses a calendar system which cuts over between the Julian calendar system and the Gregorian calendar system in 1582, skipping 10 days. So dates in 1582 or before will exhibit discrepancies - but the size of the discrepancy will vary over time - by 3 days every 400 years, on average. It so happens that between 200 and 400AD, you don't see this because that corresponds to when the discrepancy is 0.
Here's a short but complete program to demonstrate the problem:
import java.time.*;
import java.util.*;
public class Test {
public static void main(String[] args) throws Exception {
// Value obtained with Noda Time: should be 0199-12-31T22:00:00Z.
long millis = -55855792800000L;
Instant instant = Instant.ofEpochMilli(millis);
Date date = new Date(millis);
System.out.println(instant);
System.out.println(date);
}
}
Output on my machine:
0199-12-31T22:00:00Z
Tue Jan 01 22:00:00 GMT 200
This is all complicated by the problems in your initial code of assuming CAT and Africa/Harare are the same (at that point in time, Africa/Harare is regarded as having an offset of +02:10) and the incorrect day names in your strings - but it's the bug in Java which is causing the issue here.
I suggest you perform all your parsing using the java.time.format classes - then I'd hope you won't get this inconsistency.

Java time formatting

I have the method
public static void testDateFormat() throws ParseException {
DateFormat dateFormat=new SimpleDateFormat("HH:mm:ss");
Date hora;
hora=dateFormat.parse("00:00:01");
System.out.println(hora.getHours()+" "+hora.getMinutes());
System.out.println("Date "+hora);
System.out.println("Seconds "+TimeUnit.MILLISECONDS.toSeconds(hora.getTime()));
}
The output is
0 0
Date Thu Jan 01 00:00:01 COT 1970
Seconds 18001
Why the number of seconds is 18001? I expected to get 1 second.

Because your Date has a TimeZone that is not UTC. It is, in fact, COT - which is UTC-5. And 5*60*60 is 18000 (or your result, plus one second). To get the value you expect, you could call DateFormat#setTimeZone(TimeZone) like,
DateFormat dateFormat=new SimpleDateFormat("HH:mm:ss");
dateFormat.setTimeZone(TimeZone.getTimeZone("UTC")); // <-- Add this.
Date hora=dateFormat.parse("00:00:01");
System.out.println(hora.getHours()+" "+hora.getMinutes());
System.out.println("Date "+hora);
System.out.println("Seconds "+TimeUnit.MILLISECONDS.toSeconds(hora.getTime()));
Output is as you expect.
Edit
As noted in the comments, Date#getTime() per the Javadoc
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.
And your Date of
Thu Jan 01 00:00:01 COT 1970
is equivalent to
Thu Jan 01 00:05:01 UTC 1970
and thus you get the 5 hour difference.

The answer by Elliott Frisch is correct.
Time-Only
But if you are working with time-only without date or time zone, then use a date-time library that can handle that explicitly rather than hacking the java.util.Date class.
LocalTime
Use either the Joda-Time library or the java.time package in Java 8. Both offer a LocalTime class.
LocalTime localTime = LocalTime.parse( "00:00:01" );
int minuteOfHour = localTime.getMinuteOfHour();

Grab exact date without timezone interfering with XMLGregorianCalendar in Java

I have a XMLGregorianCalendar that I would like to convert to a Java Date object, but when I try to covert this:
2013-11-19T00:00:00-00:00
I always get a date with the value a day behind.
Mon Nov 18 17:00:00 MST 2013
I just want a date object containing 11/19/2013.

As commented above, the result you're getting is right - it's the same moment in time. Midnight UTC is 5PM MST the day before. Perhaps you should look into why your time is in "-00:00" instead of "-07:00" (MST)... but in the meanwhile, I suppose you could try this:
public static void main(String... args) throws DatatypeConfigurationException {
XMLGregorianCalendar xcal = DatatypeFactory.newInstance().newXMLGregorianCalendar("2013-11-19T00:00:00-00:00");
Calendar c = xcal.toGregorianCalendar();
c.setTimeZone(TimeZone.getDefault());
Date d = c.getTime();
System.out.println(d);
}
prints out Tue Nov 19 00:00:00 EST 2013, and will work for other times of day, not just midnight.

I just did this,
Date startDate = new Date(request.getStartTime().getYear(), request.getStartTime().getMonth(), request.getStartTime().getDay(), 0, 0, 0);

Get Previous Day [duplicate]

This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
How to determine the date one day prior to a given date in Java?
If I have a Java.Util.Date object, what is the best way to get an object representing the 24 hours in the past of it?

Using Java 1.6 java.util.Calendar.add:
public static Date subtractDay(Date date) {
Calendar cal = Calendar.getInstance();
cal.setTime(date);
cal.add(Calendar.DAY_OF_MONTH, -1);
return cal.getTime();
}
Others suggest using Joda Time, which is currently JSR 310, and should later be included in Java itself.

The important thing to remember is that the Date class should represent any points in time whilst the Calendar class is used to manipulate those points in time. Last of all, SimpleDateFormat will represent them as Strings.
So, the best way is to use the Calendar class to calculate the new Date for you. This will ensure that any vagaries (Daylight Saving, Leap Years and the like) are accounted for.
I'm assuming that you don't really want to find '24 Hours previous' but actually do want a new Date instance representing 'this time yesterday' - either way, you can ask the Calendar instance for a Date 24Hours prior to another or 1 Day prior.
The Daylight savings is a great example. The UK 'sprang forward' on the 26th March 2009. So, 1 day prior to 3.00a.m. on the 26.Mar.2009 should yield 3.00a.m. 25.Mar.2009 but 24 Hrs prior will yield 2.00a.m.
public class DateTests extends TestCase {
private static String EXPECTED_SUMMER_TIME = "2009.Mar.29 03:00:00";
private static String EXPECTED_SUMMER_TIME_LESS_DAY = "2009.Mar.28 03:00:00";
private static String EXPECTED_SUMMER_TIME_LESS_24_HRS = "2009.Mar.28 02:00:00";
private static String EXPECTED_SUMMER_TIME_LESS_FURTHER_24_HRS = "2009.Mar.27 02:00:00";
public void testSubtractDayOr24Hours() {
SimpleDateFormat formatter = new SimpleDateFormat("yyyy.MMM.dd HH:mm:SS");
Calendar calendar = Calendar.getInstance();
// Create our reference date, 3.00 a.m. on the day the clocks go forward (they 'went' forward at 02.00)
calendar.clear();
calendar.set(2009, 2, 29, 3, 0);
Date summerTime = calendar.getTime(); // Sun Mar 29 03:00:00 BST 2009
String formattedSummerTime = formatter.format(summerTime);
calendar.add(Calendar.DAY_OF_MONTH, -1);
// Our reference date less 'a day'
Date summerTimeLessADay = calendar.getTime(); // Sat Mar 28 03:00:00 GMT 2009
String formattedSummerTimeLessADay = formatter.format(summerTimeLessADay);
// reset the calendar instance to the reference day
calendar.setTime(summerTime);
// Our reference date less '24 hours' (is not quite 24 hours)
calendar.add(Calendar.HOUR, -24);
Date summerTimeLess24Hrs = calendar.getTime(); // Sat Mar 28 02:00:00 GMT 2009
String formattedSummerTimeLess24Hrs = formatter.format(summerTimeLess24Hrs);
// Third date shows that taking a further 24 hours from yields expected result
calendar.add(Calendar.HOUR, -24);
Date summerTimeLessFurther24Hrs = calendar.getTime(); // Fri Mar 27 02:00:00 GMT 2009
String formattedSummerTimeLessFurther24Hrs = formatter.format(summerTimeLessFurther24Hrs);
// reset the calendar once more to the day before
calendar.setTime(summerTimeLess24Hrs);
// Take a 'day' from the Sat will yield the same result as date 03 because Daylight Saving is not a factor
calendar.add(Calendar.DAY_OF_MONTH, -1);
Date summerTimeLessFurtherDay = calendar.getTime(); // Fri Mar 27 02:00:00 GMT 2009
String formattedSummerTimeLessFurtherDay = formatter.format(summerTimeLessFurtherDay);
assert(formattedSummerTime.equals(EXPECTED_SUMMER_TIME));
assert(formattedSummerTimeLessADay.equals(EXPECTED_SUMMER_TIME_LESS_DAY));
assert(formattedSummerTimeLess24Hrs.equals(EXPECTED_SUMMER_TIME_LESS_24_HRS));
assert(formattedSummerTimeLessFurther24Hrs.equals(EXPECTED_SUMMER_TIME_LESS_FURTHER_24_HRS));
// This last test proves that taking 24 hors vs. A Day usually yields the same result
assert(formattedSummerTimeLessFurther24Hrs.equals(formattedSummerTimeLessFurtherDay));
}
}
For testing date functions, wwwdot-timeanddate-dot-com is a great resource.

subtract 1000*60*60*24 from the time and create a new date.
Date yesterday = new Date(d.getTime() - (1000*60*60*24));

int dayInMs = 1000 * 60 * 60 * 24;
Date previousDay = new Date(olddate.getTime() - dayInMs);
Personally if there are a lot of time/date calculations, I'd go with Joda-time.