What is the minimum date value in Java?
Don't forget that Date constructor happily accepts negative values.
Date date = new Date(Long.MIN_VALUE);
returns
Sun Dec 02 22:47:04 BDT 292269055
I guess that's about the time of Big Bang dinosaurs :)
EDIT
As martin clayton answered, you can use the Calendar class to check the era. This will output 0 which stands for BCE:
Calendar calendar = Calendar.getInstance();
calendar.setTime(new Date(Long.MIN_VALUE));
System.out.println(calendar.get(Calendar.ERA));
If you are talking about java.util.Date as a timestamp you can do this
Date d = new Date(0L) and you will see this represents Thu Jan 01 01:00:00 GMT 1970
As tulskiy has pointed out it is possible to pass a negative value to the Date constructor. If we do this and use a date format that includes the era we can see:
Date d = new Date(Long.MIN_VALUE);
DateFormat df = new SimpleDateFormat("EEE, d MMM yyyy G HH:mm:ss Z");
System.out.println(df.format(d));
displays: Sun, 2 Dec 292269055 BC 16:47:04 +0000
The other Answers may be correct but use outmoded classes.
java.time
The old date-time classes (java.util.Date/.Calendar etc.) have been supplanted by the java.time framework built into Java 8 and later.
The java.time classes are inspired by Joda-Time, defined by JSR 310, extended by the ThreeTen-Extra project, back-ported to Java 6 & 7 by the ThreeTen-Backport project, and adapted to Android in the ThreeTenABP project. See Tutorial.
For a moment on the timeline in UTC with a resolution of nanoseconds, use Instant. Given an offset-from-UTC, use OffsetDateTime. For a time zone (offset + rules for anomalies), use ZonedDateTime, but by its nature has no defined minimum, nor does ZoneId. For a date-only value without time-of-day and without time zone, use LocalDate. For a time-of-day only value without date and without time zone, use LocalTime. For date-time without time zone, use LocalDateTime.
Instant.MIN = -1000000000-01-01T00:00Z
OffsetDateTime.MIN = -999999999-01-01T00:00:00+18:00
LocalDate.MIN = -999999999-01-01
LocalTime.MIN = 00:00
LocalDateTime.MIN = -999999999-01-01T00:00:00
Year.MIN_VALUE = -999,999,999
ZoneOffset.MIN = -18:00 (but -12:00 in practice)
Caution: Be wary of using these values as some kind of flag or special meaning. Many other software libraries and databases may not support these extreme values.
For a flag or special meaning such as a non-null "no value available", I suggest picking an arbitrary moment but avoid going to such extreme reaches either backward or forward in time. Perhaps the Unix epoch reference date, the first moment of 1970 in UTC, 1970-01-01T00:00:00Z. Defined as a constant in Java: Instant.EPOCH
It's the same as for the Calendar classes.
Try this:
Date d = new Date( Long.MIN_VALUE );
System.out.println( d );
You'll see:
Sun Dec 02 16:47:04 GMT 292269055
But the default date format doesn't include the era - which is BCE for this date.
LocalDateTime MIN defines the minimum supported LocalDateTime, '-999999999-01-01T00:00:00'.
This is the local date-time of midnight at the start of the minimum date.
public static final LocalDateTime MIN; this is the MIN syntax;
import java.time.LocalDateTime;
public class Main {
public static void main(String[] args) {
LocalDateTime a = LocalDateTime.MIN;
System.out.println(a);
}
}
Since Date is marked as Deprecated, i thought there should be another way to get around this, so i looked at some of the methods, and i found this way
You can aslo use Long.MIN_VALUE, at the time i wrote this, i hadn't searched for it, and even/so i didn't remember it.
Edited
It is mentioned in the comment that not whole class is deprecated, and still is usable, but some of its functionalities are deprecated, so you may reconsider some of those...
Note: By the time I wrote it, I used Java 8, and now we have long array of Java versions since then in which they even may reconsider methods, or change behavior or etc. that I'm not aware of, since now I program in another language.
Related
There is requirement to see if some date (ex: expiry date) is greater than or equal to today. Presently JODA time library has been used to achieve this simple comparison. Even some post are recommending that like this.
But recently found some problem with timezones. Date exists in PST and when converted to LocalDate following conversion comes false at 5:00 pm PST, when it should be true -
LocalDate now = LocalDate.fromDateFields(new Date()); // Current date in PST
LocalDate expiryDate = LocalDate.fromDateFields(expiresOn); // expiresOn is java.util.Date
boolean notExpired = expiryDate.isEqual(now) || expiryDate.isAfter(now);
When looked closely, LocalDate expiryDate was using UTC chronology. So at 5:00pm PST, when variable expiryDate contains contains "2021-01-16", variable now becomes "2021-01-17"
Please recommend, what is the better-way to deal with this problem.
I am trying to understand, what special advantages I might achieve by using joda time, because the same compassion can be done using SimpleDateFormatter.
The date-time API of java.util and their formatting API, SimpleDateFormat are outdated and error-prone. It is recommended to stop using them completely and switch to the modern date-time API.
For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7.
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.
Learn about the modern date-time API from Trail: Date Time.
LocalDate uses JVM's timezone by default
Whenever timezone is involved, make sure to specify the same while creating an instance of LocalDate. A LocalDate uses JVM's timezone by default and you should never compare a LocalDate from one timezone to that of another without converting both of them in the same timezone (the recommended one is UTC). Same is the case with LocalDateTime. Instead of using LocalDate, you should do all processing with objects which have both date and time (e.g. LocalDateTime) and if required you can derive the LocalDate from them.
Also, the java.util.Date object simply represents the number of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT (or UTC). When you print an object of java.util.Date, its toString method returns the date-time in the JVM's timezone, calculated from this milliseconds value.
Therefore, if you are deriving expiryDate from a java.util.Date object, it is essentially date-time in UTC.
You can convert now-in-PST and expiryDate into java.time.Instant and compare them. A java.time.Instant is an instantaneous point on the UTC time-line.
Demo using the modern date-time API:
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.util.Calendar;
import java.util.Date;
public class Main {
public static void main(String[] args) {
LocalDateTime nowInPST = LocalDateTime.now(ZoneId.of("America/Los_Angeles"));
System.out.println(nowInPST);
// Convert it to date in UTC
Instant nowInPSTConvertedToInstant = nowInPST.atZone(ZoneId.of("America/Los_Angeles"))
.withZoneSameInstant(ZoneId.of("Etc/UTC"))
.toInstant();
// Some java.util.Date
Calendar calendar = Calendar.getInstance();
calendar.set(2020, 0, 10, 10, 10, 10);
Date date = calendar.getTime();
Instant expiry = date.toInstant();
System.out.println(nowInPSTConvertedToInstant.isBefore(expiry));
}
}
Output:
2021-01-17T10:58:38.490041
false
Note: Check the following notice at the Home Page of Joda-Time
Joda-Time is the de facto standard date and time library for Java
prior to Java SE 8. Users are now asked to migrate to java.time
(JSR-310).
Simplify your expression
The following statement
boolean notExpired = expiryDate.isEqual(now) || expiryDate.isAfter(now);
can be simplified as
boolean notExpired = !expiryDate.isBefore(now);
You should consider two APIs:
Joda-Time that you have been using until now is a good library, but in maintenance mode.
The chief developer of Joda-Time, Stephen Colebourne, went on to develop java.time, the modern Java date and time API, drawing on lessons from good and not so good experiences from Joda-Time.
It’s not perfectly clear from your question. I am assuming that expiration has been recorded in UTC and appears to be one day early because it is looked at in Pacific Time. So I am showing you how to keep everything in UTC so comparisons make sense and are accurate.
Joda-Time
System.setProperty("user.timezone", "America/Vancouver");
Date expiresOn = new Date(1_610_841_600_000L); // Jan 17 UTC
System.out.println(expiresOn);
LocalDate now = LocalDate.now(DateTimeZone.UTC);
System.out.println(now);
LocalDate expiryDate = new DateTime(expiresOn, DateTimeZone.UTC).toLocalDate();
System.out.println(expiryDate);
boolean notExpired = expiryDate.isEqual(now) || expiryDate.isAfter(now);
System.out.println("Expired? " + (notExpired ? "No" : "Yes"));
Output when running now:
Sat Jan 16 16:00:00 PST 2021
2021-01-17
2021-01-17
Expired? No
The Joda-Time home page says:
Note that Joda-Time is considered to be a largely “finished” project.
No major enhancements are planned. If using Java SE 8, please migrate
to java.time (JSR-310).
java.time
LocalDate now = LocalDate.now(ZoneOffset.UTC);
System.out.println(now);
LocalDate expiryDate = expiresOn.toInstant()
.atOffset(ZoneOffset.UTC)
.toLocalDate();
System.out.println(expiryDate);
boolean notExpired = expiryDate.isEqual(now) || expiryDate.isAfter(now);
System.out.println("Expired? " + (notExpired ? "No" : "Yes"));
2021-01-17
2021-01-17
Expired? No
A note on taste
My taste is for avoiding unnecessary negations in variable names (and elsewhere). I’d find it simpler to do:
boolean expired = expiryDate.isBefore(now);
System.out.println("Expired? " + expired);
Expired? false
Links
Joda-Time Home
Oracle tutorial: Date Time explaining how to use java.time.
Below code in India returns "1970-01-01" for 0L and in Canada it returns "1969-12-31". I have no clue what is going wrong here, Can anyone tell me what is the problem here. I suspect it is because of timezone issue but need more information on it.
public static RestEDate convertLongDateToStringDate(long lDate) {
String returnDate = "";
if (lDate >= 0) {
returnDate = new SimpleDateFormat("yyyy-MM-dd").format(new Date(lDate));
}
return new RestEDate(returnDate);
}
Yes, it's a timezone issue. Your SimpleDateFormat instance is defaulting to the current timezone. Midnight Jan 1st 1970 GMT (which is what 0L means) is 19:00 Dec 31st, 1969 on the east coast of Canada (GMT-0500) and 16:00 Dec 31st, 1969 on the west coast of Canada (GMT-0800). The Date instance is correct, but how that's interpreted depends on what timezone your formatter is using.
To set the timezone used by SimpleDateFormat (for instance, to GMT), use its setTimeZone method (or setCalendar if you already have a Calendar around you want to use).
The answer by T.J. Crowder is correct.
Joda-Time || java.time > java.util.Date
Better to use either the Joda-Time library or the similar java.time package built into Java 8. Either is vastly superior to the mess that is the java.util.Date and .Calendar classes.
Assign Time Zone
In both of these libraries, a date-time object knows it's own assigned time zone. If not specified, the JVM’s default time zone is applied. Better to specify the desired time zone rather than rely implicitly on default.
Use proper time zone names. Avoid the common 3 or 4 letter codes which are neither standardized nor unique.
In the example below, Montréal is five hours behind UTC.
Joda-Time Example
Here is a Joda-Time 2.6 example.
DateTimeZone zoneMontreal = DateTimeZone.forID( "America/Montreal" );
DateTime dateTimeZeroInMontreal = new DateTime( 0L, zoneMontreal );
DateTime dateTimeZeroInUtc = dateTimeZeroInMontreal.withZone( DateTimeZone.UTC );
When run.
dateTimeZeroInMontreal : 1969-12-31T19:00:00.000-05:00
dateTimeZeroInUtc : 1970-01-01T00:00:00.000Z
I am doing this to set a date format and then convert it into date datatype but it is not giving expected results.
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
DateFormat formatter = new SimpleDateFormat("yyyy/MM/dd");
String cur_date=dateFormat.format(new Date());
myDb.setDOB(formatter.parse(cur_date));
Scenario is: I want current date to be converted in yyyy/mm/dd and then pass it in setDOB(Date date).
EDIT:Result added Result is Tue Jan 01 00:08:00 IST 2013
GUYS! I am not using 'mm',here I just mistakenly wrote mm in DateFormat it is also MM
EDIT AGAIN First I just used setDOB(new Date() ); but got formatting issue,
then I used SimpleDateFormat.format to set yyyy/MM/dd but it returns String so used
DateFormat.parse to convert it back into date type.
You're not using the same format. Case matters! "MM" is for months, "mm" is for minutes.
The issue is you MM in the format.
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
DateFormat formatter = new SimpleDateFormat("yyyy/mm/dd");
MM is month
mm is minute
Refer here for the detailed formats. So it should have been,
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
DateFormat formatter = new SimpleDateFormat("yyyy/MM/dd");
+1 mael for spotting the format issue first, however...
Date is a container for the number of milliseconds since the epoch (Jan-1970-01-01 GMT), it does not care about the format of the values.
For example, the following...
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
DateFormat formatter = new SimpleDateFormat("yyyy/MM/dd");
Date now = new Date();
String cur_date = dateFormat.format(now);
try {
System.out.println("Now = " + now);
System.out.println("cur_date = " + cur_date);
System.out.println("dateFormat.parse(cur_date) = " + dateFormat.parse(cur_date));
} catch (ParseException exp) {
exp.printStackTrace();
}
Outputs...
Now = Thu Aug 01 18:08:39 EST 2013
cur_date = 2013/08/01
dateFormat.parse(cur_date) = Thu Aug 01 00:00:00 EST 2013
So you can lose important data about the date by doing this...
Leave formatting to when you want to display the value, not when you want to store it (if you can get away with it)
It sounds like you're expecting a Date to "know" its format. It doesn't. A Date object just contains a number of milliseconds since the Unix epoch. It doesn't know about time zones, or calendars, or string formats. It's just a date.
So your code should just be:
myDb.setDOB(new Date());
... and then handle the formatting of that wherever you're displaying it.
You re using different date String patterns. MM is for months, mm is for minutes (see SimpleDateFormat API)
Your setDOB is taking a Date object. I fail to see why you might want to format your date when giving it is as a parameter in your method call. Usually one formats a date when it needs to be rendered / stored somewhere.
formatter.parse is used to parse the String Date, It returns Date Object.
The date is represented as a Date object or as the milliseconds as example since January 1, 1970, 00:00:00 GMT.
I am not getting what actually your doing. Date object is always represented as in the above format.
The Question and other Answers all use troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
LocalDate
Apparently you want a date-only value.
The LocalDate class represents a date-only value without time-of-day and without time zone.
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.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-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" ); // Or "Asia/Kolkata" , "Pacific/Auckland" , etc.
LocalDate today = LocalDate.now( z );
Generating strings
To generate a string representing the value of that LocalDate, simply call toString(). That method generates a string in standard ISO 8601 format.
String output = today.toString();
2017-01-23
Your desired format is close to that, using slash characters in place of hyphens. I suggest sticking with the standard formats whenever possible. But if you insist, just replace the characters.
String output = today.toString().replace( "-" , "/" );
For other formats use the DateTimeFormatter class. And be aware of that class’ ability to automatically localize while generating a string.
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
I have a Date object which represents a UTC time. When I use the method getTime() to get the long value of this object, the value returned corresponds to our local time (central US). What is the correct way to get the value back which corresponds to the original UTC time?
Thanks
tl;dr
Instant.now()
…and…
Instant.ofEpochMilli( n )
…and…
instant.toEpochMilli()
Date is always in UTC
When I use the method getTime() to get the long value of this object, the value returned corresponds to our local time (central US).
No, the value returned from Date::getTime() always corresponds to UTC (virtually the same thing as GMT in this context). To quote the class doc:
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.
So your Question is nonsensical in that a Date is already in UTC. No need to “get the value back which corresponds to the original UTC time”,
You may be confusing the behavior of getTime with that of the toString method. The toString method annoyingly and confusingly applies the current default time zone in the process of generating the String. So the string output appears with a time zone while in fact there is no time zone to be set or gotten from the Date itself. (There actually is a zone deep within the Date but that is irrelevant to this discussion here. This class is a confusing mess!)
java.time
The modern way to do this is using java.time classes.
Instant
The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Get the current moment.
Instant instant = Instant.now();
You can convert a Date to its modern replacement by calling one of the new conversion methods added to the old date-time classes. Just call toInstant, quite easy.
Instant instant = myJavaUtilDate.toInstant();
I do not recommend at all using a count-from-epoch number as a way of tracking time. Stick with the java.time objects instead. When outside Java, serialize to text use the ISO 8601 formats.
But if you must, you can extract a count of milliseconds since epoch of 1970-01-01T00:00:00Z. Note that this may involve data loss! An Instant has a finer resolution of nanoseconds. So going to milliseconds may lop off a fraction of the fraction of a second.
long millisecondsSinceEpoch = instant.toEpochMilli(); // Caution: Possible data-loss in going from nanoseconds to milliseconds.
Going the other direction, from a count to an Instant.
Instant instant = Instant.ofEpochMilli( millisecondsSinceEpoch ) ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8 and SE 9 and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
See How to use….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
The DateFormat class has a method for setting your preferred time zone, and there's a time zone class that has a setting for UTC time.
So, for example,
SimpleDateFormat sdf = new SimpleDateFormat();
sdf.setTimeZone(new SimpleTimeZone(SimpleTimeZone.UTC_TIME, "UTC"));
Date yourUtcDate = sdf.parse(yourOriginalDate);
java.util.Date has no concept of timezone. It simply holds time relative to epoch, which is Jan 1 1970 00:00:00 UTC. Date is a model, separate from the view. When you display the date, the concept of timezone then is applied. Date's toString() displays a human readable date in the default timezone. You can either use a DateFormat to display a Date in a different timezone (such as UTC), or change the JVM's default timezone.
getTime() returns "the number of milliseconds since January 1, 1970, 00:00:00 GMT", nothing more, nothing less (obviously, you have to create it correctly). You can format it however you want, starting with e.g. the GregorianCalendar(TimeZone) constructor.
Most of the Date class functions are deprecated as they are now shifted in Calendar class.
Here is code to get UTC time from Calendar.
Date date = new Date(timeStamp);
Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(TimeZone.getTimeZone("UTC"));
calendar.setTime(date);
Here is the sample code to get the year, month, etc.
System.out.println(calendar.get(Calendar.YEAR));
System.out.println(calendar.get(Calendar.MONTH));
Calendar also has support for many other useful information like, TIME, DAY_OF_MONTH, etc. Here the documentation listing all of them Please note that the month are 0 based. January is 0th month.
LocalDateTime now = LocalDateTime.now(Clock.systemUTC());
Instant instant = now.atZone(ZoneId.systemDefault()).toInstant();
Date formattedDate = Date.from(instant);
return formattedDate;
I need today's date - and zero anything else (" 05/06/08 00:00:00 ")
I've tried
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.HOUR, 0);
Date date1 = calendar.getTime();
System.out.println(date1);
Run: (This is seriously messed up)
If the hour on the computer is < 12:00 at noon : Sun Mar 08 00:44:39 IST 2009
If the hour on the computer is > 12:00 at noon : Sun Mar 08 12:46:53 IST 2009
So I gave this up.
All the Date's setters are deprecated (except the epoch time) - so I don't want to use them either
The only thing I could think of is
Calendar calendar = Calendar.getInstance();
SimpleDateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
String sDate = dateFormat.format(calendar.getTime());
Date today = dateFormat.parse(sDate);
But this is such a lame code I can't bring myself to write it.
Any other option?
Thanks!
I use this:
public static Date startOfDay(Date date) {
Calendar dCal = Calendar.getInstance();
dCal.setTime(date);
dCal.set(Calendar.HOUR_OF_DAY, 0);
dCal.set(Calendar.MINUTE, 0);
dCal.set(Calendar.SECOND, 0);
dCal.set(Calendar.MILLISECOND, 0);
return dCal.getTime();
}
My standard advice for Java date/time questions: don't use java.util.{Calendar,Date}. Use Joda Time. That way you can represent a date as a date (with no associated time zone), instead of a date/time. Or you could use a DateMidnight if that's what you want to represent. (Be careful of combinations of time zone and date where there is no midnight though...)
What do you need to use the Date with? If you can get away with changing to use Joda throughout, that's great. Otherwise, you can use Joda to do what you want and then convert to milliseconds (and then to java.util.Date) when you really need to.
(Michael's solution when using Date/Calendar is fine if you really want to stick within a broken API... but I can't overstate how much better Joda is...)
You should use HOUR_OF_DAY instead of HOUR and combine it with MINUTE and SECOND also.
import java.util.Calendar;
import static java.util.Calendar.HOUR_OF_DAY;
import static java.util.Calendar.MINUTE;
import static java.util.Calendar.SECOND;
import static java.util.Calendar.MILLISECOND;
public class Today {
public static void main( String [] args ) {
Calendar cal = Calendar.getInstance();
cal.set( HOUR_OF_DAY, 0 );
cal.set( MINUTE, 0 );
cal.set( SECOND, 0 );
cal.set( MILLISECOND, 0 );
System.out.println( cal.getTime() );
}
}
The results you are getting are due to HOUR is used to AM/PM while HOUR_OF_DAY is 24 hrs.
HOUR_OF_DAY:
Field number for get and set indicating the hour of the day. HOUR_OF_DAY is used for the 24-hour clock. E.g., at 10:04:15.250 PM the HOUR_OF_DAY is 22.
HOUR:
Field number for get and set indicating the hour of the morning or afternoon. HOUR is used for the 12-hour clock (0 - 11). Noon and midnight are represented by 0, not by 12. E.g., at 10:04:15.250 PM the HOUR is 10.
The time component is not just hours (and Calendar.HOUR is, as you have noticed, AM/PM).
You need to set all of the time fields to 0: HOUR_OF_DAY, MINUTE, SECOND, MILLISECOND.
See Apache's commons-lang DateUtils.truncate()
java.time
The java.util Date-Time API and their formatting API, SimpleDateFormat are outdated and error-prone. It is recommended to stop using them completely and switch to the modern Date-Time API*.
Also, quoted below is a notice from the home page of Joda-Time:
Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.
Solution using java.time, the modern Date-Time API:
The modern Date-Time API has many types which truly represent a date or time or date-time in a specific timezone. You can choose from the following options as per your specific requirement:
If you are looking for a type that represents a date without a timezone, you can use LocalDate.now. The good news is that its variant, LocalDate#now(ZoneId) returns the current date from the system clock in the specified time-zone.
If you are looking for an object that represents a date without a timezone, and with time units set to zero, you can call LocalDate#atStartOfDay on the object obtained with Option#1.
If you are looking for an Instant representing the Date-Time object obtained with Option#2, you can attach this object with ZoneId.of("Etc/UTC") using LocalDateTime#atZone to obtain a ZonedDateTime and convert the same into an Instant using ZonedDateTime#toInstant.
Demo:
import java.time.Instant;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
public class Main {
public static void main(String[] args) {
LocalDate todayInSystemTz = LocalDate.now();
System.out.println(todayInSystemTz);
LocalDate todayInIndia = LocalDate.now(ZoneId.of("Asia/Kolkata"));
System.out.println(todayInIndia);
LocalDateTime todayInSystemTzWithZeroTimeUnits = todayInSystemTz.atStartOfDay();
System.out.println(todayInSystemTzWithZeroTimeUnits);
ZonedDateTime todayInUtcWithZeroTimeUnits = todayInSystemTzWithZeroTimeUnits.atZone(ZoneId.of("Etc/UTC"));
System.out.println(todayInUtcWithZeroTimeUnits);
Instant instant = todayInUtcWithZeroTimeUnits.toInstant();
System.out.println(instant);
// Can I represent the obtained Instant in India?
System.out.println(instant.atZone(ZoneId.of("Asia/Kolkata")));
// Can I represent the obtained Instant in New York?
System.out.println(instant.atZone(ZoneId.of("America/New_York")));
}
}
Output:
2021-06-20
2021-06-20
2021-06-20T00:00
2021-06-20T00:00Z[Etc/UTC]
2021-06-20T00:00:00Z
2021-06-20T05:30+05:30[Asia/Kolkata]
2021-06-19T20:00-04:00[America/New_York]
ONLINE DEMO
The Z in the output is the timezone designator for zero-timezone offset. It stands for Zulu and specifies the Etc/UTC timezone (which has the timezone offset of +00:00 hours).
For any reason, if you need to convert this object of Instant to an object of java.util.Date**, you can do so as follows:
Date date = Date.from(instant);
Learn more about the modern Date-Time API from Trail: Date Time.
* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. 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.
**
A java.util.Date object simply represents the number of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT (or UTC). Since it does not hold any timezone information, its toString function applies the JVM's timezone to return a String in the format, EEE MMM dd HH:mm:ss zzz yyyy, derived from this milliseconds value. To get the String representation of the java.util.Date object in a different format and timezone, you need to use SimpleDateFormat with the desired format and the applicable timezone e.g.
Date date = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX", Locale.ENGLISH);
sdf.setTimeZone(TimeZone.getTimeZone("America/New_York"));
String strDateNewYork = sdf.format(date);
sdf.setTimeZone(TimeZone.getTimeZone("Etc/UTC"));
String strDateUtc = sdf.format(date);
As mentioned above you should use
Calendar.HOUR_OF_DAY
As opposed to
Calendar.HOUR
Also you need to clear out the other fields (Calendar.MINUTE, Calendar.SECOND, and Calendar.MILLISECOND) by setting them to zero.
Sorry there's no easy way here. A pain, and that's why they're working on a new API for Java 7 I believe based on Joda Time.
...or you can do it the hacker way:
long MS_PER_DAY = 86400000L;
Date dateTime=new Date();
long offset = TimeZone.getDefault().getOffset(dateTime.getTime());
Date date= new Date(((dateTime.getTime()+offset)/MS_PER_DAY)*MS_PER_DAY-offset);
I know this is a very old question, no longer active, but it came to be on the top when I searched Google.
While all advise is very good, I can't believe no one simply answered:
Date date = new Date(System.currentTimeMillis());
System.out.println(date);
Which returns effectively, today's date.
Why the string manipulation?
Can you not just set the values you need on the Calendar object before converting to a Date using getTime()?
Another vote for JodaTime.
java.util.Date and Calendar are so bad they are broken. (And SimpleDateFormat is rubbish too!)
For what it's worth, Java 7 will include a new date time library based strongly around JodaTime.