What's the best way to get the current date/time in Java?
There is no "best" way.
It depends on what form of date / time you want:
If you want the date / time as a single numeric value, then
System.currentTimeMillis()gives you that, expressed as the number of milliseconds after the UNIX epoch (as a Javalong). This value is a delta from a UTC time-point, and is independent of the local time-zone1.If you want the date / time in a form that allows you to access the components (year, month, etc) numerically, you could use one of the following:
new Date()gives you aDateobject initialized with the current date / time. The problem is that theDateAPI methods are mostly flawed ... and deprecated.Calendar.getInstance()gives you aCalendarobject initialized with the current date / time, using the defaultLocaleandTimeZone. Other overloads allow you to use a specificLocaleand/orTimeZone. Calendar works ... but the APIs are still cumbersome.new org.joda.time.DateTime()gives you a Joda-time object initialized with the current date / time, using the default time zone and chronology. There are lots of other Joda alternatives ... too many to describe here. (But note that some people report that Joda time has performance issues.; e.g. https://stackoverflow.com/questions/6280829.)in Java 8, calling
java.time.LocalDateTime.now()andjava.time.ZonedDateTime.now()will give you representations2 for the current date / time.
Prior to Java 8, most people who know about these things recommended Joda-time as having (by far) the best Java APIs for doing things involving time point and duration calculations.
With Java 8 and later, the standard java.time package is recommended. Joda time is now considered "obsolete", and the Joda maintainers are recommending that people migrate3.
Note: the Calendar, org.joda.time and java.time solutions can use either the platform's default timezone or an explicit timezone provided via constructor arguments. Generally, using an explicit timezone rather than the default zone will make your application's behavior more predictable / less susceptible to problems if (for example) you redeploy to a data center in a different timezone.
But no matter what you do, you (and maybe your application) should be aware that the timezone of the user, your service and the data center can all be different. The concept of the "current date/time" is complicated.
1 - System.currentTimeMillis() gives the "system" time. While it is normal practice for the system clock to be set to (nominal) UTC, there will be a difference (a delta) between the local UTC clock and true UTC. The size of the delta depends on how well (and how often) the system's clock is synced with UTC.
2 - Note that LocalDateTime doesn't include a time zone. As the javadoc says: "It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
3 - Note: your Java 8 code won't break if you don't migrate, but the Joda codebase may eventually stop getting bug fixes and other patches. As of 2020-02, an official "end of life" for Joda has not been announced, and the Joda APIs have not been marked as Deprecated.
What's the best way to get the current date/time in Java?
There is no "best" way.
It depends on what form of date / time you want:
If you want the date / time as a single numeric value, then
System.currentTimeMillis()gives you that, expressed as the number of milliseconds after the UNIX epoch (as a Javalong). This value is a delta from a UTC time-point, and is independent of the local time-zone1.If you want the date / time in a form that allows you to access the components (year, month, etc) numerically, you could use one of the following:
new Date()gives you aDateobject initialized with the current date / time. The problem is that theDateAPI methods are mostly flawed ... and deprecated.Calendar.getInstance()gives you aCalendarobject initialized with the current date / time, using the defaultLocaleandTimeZone. Other overloads allow you to use a specificLocaleand/orTimeZone. Calendar works ... but the APIs are still cumbersome.new org.joda.time.DateTime()gives you a Joda-time object initialized with the current date / time, using the default time zone and chronology. There are lots of other Joda alternatives ... too many to describe here. (But note that some people report that Joda time has performance issues.; e.g. https://stackoverflow.com/questions/6280829.)in Java 8, calling
java.time.LocalDateTime.now()andjava.time.ZonedDateTime.now()will give you representations2 for the current date / time.
Prior to Java 8, most people who know about these things recommended Joda-time as having (by far) the best Java APIs for doing things involving time point and duration calculations.
With Java 8 and later, the standard java.time package is recommended. Joda time is now considered "obsolete", and the Joda maintainers are recommending that people migrate3.
Note: the Calendar, org.joda.time and java.time solutions can use either the platform's default timezone or an explicit timezone provided via constructor arguments. Generally, using an explicit timezone rather than the default zone will make your application's behavior more predictable / less susceptible to problems if (for example) you redeploy to a data center in a different timezone.
But no matter what you do, you (and maybe your application) should be aware that the timezone of the user, your service and the data center can all be different. The concept of the "current date/time" is complicated.
1 - System.currentTimeMillis() gives the "system" time. While it is normal practice for the system clock to be set to (nominal) UTC, there will be a difference (a delta) between the local UTC clock and true UTC. The size of the delta depends on how well (and how often) the system's clock is synced with UTC.
2 - Note that LocalDateTime doesn't include a time zone. As the javadoc says: "It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
3 - Note: your Java 8 code won't break if you don't migrate, but the Joda codebase may eventually stop getting bug fixes and other patches. As of 2020-02, an official "end of life" for Joda has not been announced, and the Joda APIs have not been marked as Deprecated.
(Attention: only for use with Java versions <8. For Java 8+ check other replies.)
If you just need to output a time stamp in format YYYY.MM.DD-HH.MM.SS (very frequent case) then here's the way to do it:
String timeStamp = new SimpleDateFormat("yyyyMMdd_HHmmss").format(Calendar.getInstance().getTime());
Videos
Date today = new Date();
today.setHours(0); //same for minutes and seconds
Since the methods are deprecated, you can do this with Calendar:
Calendar today = Calendar.getInstance();
today.set(Calendar.HOUR_OF_DAY, 0); // same for minutes and seconds
And if you need a Date object in the end, simply call today.getTime()
Date today = DateUtils.truncate(new Date(), Calendar.DAY_OF_MONTH);
DateUtils from Apache Commons-Lang. Watch out for time zone!
Just construct a new Date object without any arguments; this will assign the current date and time to the new object.
import java.util.Date;
Date d = new Date();
In the words of the Javadocs for the zero-argument constructor:
Allocates a Date object and initializes it so that it represents the time at which it was allocated, measured to the nearest millisecond.
Make sure you're using java.util.Date and not java.sql.Date -- the latter doesn't have a zero-arg constructor, and has somewhat different semantics that are the topic of an entirely different conversation. :)
tl;dr
Instant.now()
java.time
The java.util.Date class has been outmoded by the new java.time package (Tutorial) in Java 8 and later. The old java.util.Date/.Calendar classes are notoriously troublesome, confusing, and flawed. Avoid them.
ZonedDateTime
Get the current moment in java.time.
ZonedDateTime now = ZonedDateTime.now();
A ZonedDateTime encapsulates:
- Date.
- Time-of-day, with a fraction of a second to nanosecond resolution.
- Time zone.
If no time zone is specified, your JVM’s current default time zone is assigned silently. Better to specify your desired/expected time zone than rely implicitly on default.
ZoneId z = ZoneId.of( "Pacific/Auckland" );
ZonedDateTime zdt = ZonedDateTime.now( z );
UTC
Generally better to get in the habit of doing your back-end work (business logic, database, storage, data exchange) all in UTC time zone. The code above relies implicitly on the JVM’s current default time zone.
The Instant class represents a moment in the timeline in UTC with a resolution of nanoseconds.
Instant instant = Instant.now();
The Instant class is a basic building-block class in java.time and may be used often in your code.
When you need more flexibility in formatting, transform into an OffsetDateTime. Specify a ZoneOffset object. For UTC use the handy constant for UTC.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC );
Time Zone
You easily adjust to another time zone for presentation to the user. Use a proper time zone name, never the 3-4 letter codes such as EST or IST.
ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime nowMontreal = instant.atZone( z );
Generate a String representation of that date-time value, localized.
String output = DateTimeFormatter
.ofLocalizedDate( FormatStyle.FULL )
.withLocale( Locale.CANADA_FRENCH )
.format ( nowMontreal );
Instant
Or, to stay in UTC, use Instant. An Instant object represents a moment on the timeline, to nanosecond resolution, always in UTC. This provides the building block for a zoned date-time, along with a time zone assignment. You can think of it conceptually this way:
ZonedDateTime=Instant+ZoneId
You can extract an Instant from a ZonedDateTime.
Instant instantNow = zdt.toInstant();
You can start with an Instant. No need to specify a time zone here, as Instant is always in UTC.
Instant now = Instant.now();