LocalDate to java.util.Date and vice versa simplest conversion? [duplicate]

Asked 11/10, 2015 at 15:48 Answered 8/12, 2017 at 17:39

185

Is there a simple way to convert a LocalDate (introduced with Java 8) to java.util.Date object?

By 'simple', I mean simpler than this:

Date date = Date.from(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant());

which seems a bit awkward to me.

Since we are interested only in the date portion and there is no timezone information in neither of the objects, why introduce time zones explicitly? The midnight time and the system default timezone should be taken implicitly for the conversion.

Reconnoiter answered 11/10, 2015 at 15:48 Comment(9)

If youre using Java 8 you should probably avoid java.util.Date altogether – Fogdog 11/10, 2015 at 15:54

"Since we are interested only in the date portion" problem is that java.util.Date by default is expected not only to represent informations about day (year/month/day), but also about time of day so we need to somehow provide this informations (here helps atStartOfDay). – Wareroom 11/10, 2015 at 15:54

A LocalDate is not an instant in time, it is a date, such as "30 Jan 2014". It is not tied to any particular instant until you give it a time zone. I'm not entirely sure you understand what you are asking... – Piddle 11/10, 2015 at 15:55

A Date represents a precise instant. A LocalDate doesn't. It's just a set of fields. You thus need to specify a timezone to transform this set of fields to an instant: 2015-10-11T00:00 is not the same instant in Paris and in New York. – Jennette 11/10, 2015 at 15:56

@Fogdog Actually that is the case. As I am using the new java time api, there are APIs (e.g. JDBC) which takes dates and times from java.util or java.sql packages. Hence the required conversion. – Reconnoiter 11/10, 2015 at 19:20

@JBNizet I'm not certain that that's the easiest way to understand it. Both Date and Instant are internally reckoned in UTC and (thankfully) have no notion of local time zone. LocalDate and LocalDateTime are intended to represent their respective temporal values in arbitrary local time zones which most of the time are not UTC. Hence there is no simple, historically consistent way to directly convert from one form to the other without knowing more information. – Staging 11/10, 2015 at 20:5

@Reimeus: if he's using an older API, then he may have no choice but to use Date. The @Basic annotation of JPA 2.1, for example, directly recognizes Date and Calendar but will only work with Instant as a serializable type. I would say he's doing the right thing by using the new Date-Time API in his new code and using Date to interoperate. – Staging 11/10, 2015 at 20:10

"Since we are interested only in the date portion and there is no timezone information in neither of the objects why introduce time zones here?" ... you may think there is no time zone here, but there always is whenever (whenever) there is a notion of time. The timestamps "07-Sep-2015T17:30" and "07-Sep-2015T22:30" in U.S. Central Daylight Time have the same dates locally but different dates in UTC (and, therefore, different dates as Instants). – Staging 11/10, 2015 at 20:20

@George: the general contract for Date and Instant both include the notion of time. Interconverting between LocalDate and Date therefore means that you are necessarily dealing with a notion of time, even if you don't intend to use time information. You can't convert from "07-Sept-2015 in some local time zone" (LocalDate) to "milliseconds since midnight 01-Jan-1970 UTC" (Date) without knowing what "some local time zone" is. – Staging 11/10, 2015 at 22:4

203

tl;dr

Is there a simple way to convert a LocalDate (introduced with Java 8) to java.util.Date object? By 'simple', I mean simpler than this

Nope. You did it properly, and as concisely as possible.

java.util.Date.from(                     // Convert from modern java.time class to troublesome old legacy class.  DO NOT DO THIS unless you must, to inter operate with old code not yet updated for java.time.
    myLocalDate                          // `LocalDate` class represents a date-only, without time-of-day and without time zone nor offset-from-UTC. 
    .atStartOfDay(                       // Let java.time determine the first moment of the day on that date in that zone. Never assume the day starts at 00:00:00.
        ZoneId.of( "America/Montreal" )  // Specify time zone using proper name in `continent/region` format, never 3-4 letter pseudo-zones such as “PST”, “CST”, “IST”. 
    )                                    // Produce a `ZonedDateTime` object. 
    .toInstant()                         // Extract an `Instant` object, a moment always in UTC.
)

Read below for issues, and then think about it. How could it be simpler? If you ask me what time does a date start, how else could I respond but ask you “Where?”?. A new day dawns earlier in Paris FR than in Montréal CA, and still earlier in Kolkata IN, and even earlier in Auckland NZ, all different moments.

So in converting a date-only (LocalDate) to a date-time we must apply a time zone (ZoneId) to get a zoned value (ZonedDateTime), and then move into UTC (Instant) to match the definition of a java.util.Date.

Details

Firstly, avoid the old legacy date-time classes such as java.util.Date whenever possible. They are poorly designed, confusing, and troublesome. They were supplanted by the java.time classes for a reason, actually, for many reasons.

But if you must, you can convert to/from java.time types to the old. Look for new conversion methods added to the old classes.

`java.util.Date` → `java.time.LocalDate`

Keep in mind that a java.util.Date is a misnomer as it represents a date plus a time-of-day, in UTC. In contrast, the LocalDate class represents a date-only value without time-of-day and without time zone.

Going from java.util.Date to java.time means converting to the equivalent class of java.time.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).

Instant instant = myUtilDate.toInstant();

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.

So we need to move that Instant into a time zone. We apply ZoneId to get a ZonedDateTime.

ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone( z );

From there, ask for a date-only, a LocalDate.

LocalDate ld = zdt.toLocalDate();

`java.time.LocalDate` → `java.util.Date`

To move the other direction, from a java.time.LocalDate to a java.util.Date means we are going from a date-only to a date-time. So we must specify a time-of-day. You probably want to go for the first moment of the day. Do not assume that is 00:00:00. Anomalies such as Daylight Saving Time (DST) means the first moment may be another time such as 01:00:00. Let java.time determine that value by calling atStartOfDay on the LocalDate.

ZonedDateTime zdt = myLocalDate.atStartOfDay( z );

Now extract an Instant.

Instant instant = zdt.toInstant();

Convert that Instant to java.util.Date by calling from( Instant ).

java.util.Date d = java.util.Date.from( instant );

More info

Oracle Tutorial
Similar Question, Convert java.util.Date to what “java.time” type?

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.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes. Hibernate 5 & JPA 2.2 support java.time.

Where to obtain the java.time classes?

Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 brought some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android (26+) bundle implementations of the java.time classes.
- For earlier Android (<26), a process known as API desugaring brings a subset of the java.time functionality not originally built into Android.
  - If the desugaring does not offer what you need, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above) to Android. 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.

Dare answered 20/10, 2016 at 0:38 Comment(1)

I like this answer because it contains both the tl and the dr part, thanks – Chisel 27/11, 2017 at 9:24

144

Disclaimer: While the answer below works, it is not recommended to be used in production code. The approach in the Basil's answer should be followed in this case.

Actually there is. There is a static method valueOf in the java.sql.Date object which does exactly that. So we have

java.util.Date date = java.sql.Date.valueOf(localDate);

and that's it. No explicit setting of time zones because the local time zone is taken implicitly.

From docs:

The provided LocalDate is interpreted as the local date in the local time zone.

The java.sql.Date subclasses java.util.Date so the result is a java.util.Date also.

And for the reverse operation there is a toLocalDate method in the java.sql.Date class. So we have:

LocalDate ld = new java.sql.Date(date.getTime()).toLocalDate();

Reconnoiter answered 11/10, 2015 at 15:51 Comment(6)

The original question Date is also in system timezone. Using java.sql.Date for a actual date is not that far fetched, IMHO. – Lipase 11/10, 2015 at 17:4

This answer can NOT be recommended because a) it lacks support for different timezones and b) mix up two different types where the inheritance relationship only denotes an implementation-driven dependency. The type java.sql.Date should only be applied in context of JDBC. Best answer see that from @Basil Bourque – Handlebar 21/10, 2016 at 10:19

As Hochschild said, the class doc tells us to ignore the inheritance subclass relationship between java.util.Date & java.sql.Date, tells us to not do what this Answer does. Furthermore that valueOf method does not skirt the issue of time zone, it merely hides the issue while silently applying the JVM’s current default zone in setting the time-of-day to midnight. So the statement “No time zones, no complications” is incorrect: There are time zones involved, and there are complications, you've just chosen to ignore them. The java.time classes were invented for a reason; use them. – Dare 18/11, 2016 at 16:20

As the author of the java.time.* libraries I am saddened that over 40 people have seen fit to upvote this. The correct answer is here and Basil's below. Using java.sql.Date is a horrible hack as expressed in other comments and this approach hides the time-zone conversion, which is a Bad Thing. It has also been known for years that java.sql.Date should never have extended java.util.Date. Finally, when using modules in Java 9, the java.sql classes will be a separate dependency, so using this hack will have consequences. – Feaze 16/3, 2017 at 9:27

@Feaze I think the problem lies with old JDBC APIs which pass back java.sql.Dates which can then easily be cast down to java.util.Date by unsuspecting intermediate classes and then when you call java.util.Date::toInstant(), you get an UnsupportedOperationException from java.sql.Date :( – Hyperbaric 17/10, 2017 at 15:7

Its a hack at best. Please ignore this answer. And instead see @BasilBourque's answer – Kris 30/11, 2017 at 12:3

Date -> LocalDate:

LocalDate localDate = date.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();

LocalDate -> Date:

Date date = Date.from(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant());

Fauch answered 1/8, 2017 at 2:52 Comment(1)

if your java.util.Date is actually a java.sql.Date, then this will give you an UnsupportedOperationException – Hyperbaric 17/10, 2017 at 14:55

Converting LocalDateTime to java.util.Date

    LocalDateTime localDateTime = LocalDateTime.now();

    ZonedDateTime zonedDateTime = localDateTime.atZone(ZoneOffset.systemDefault());

    Instant instant = zonedDateTime.toInstant();

    Date date = Date.from(instant);

System.out.println("Result Date is : "+date);

Archivolt answered 23/11, 2017 at 9:28 Comment(0)

Date to LocalDate

Date date = new Date();
LocalDate localDate = date.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();

LocalDate to Date

LocalDate localDate = LocalDate.now();
Date date = Date.from(localDate.atStartOfDay(ZoneId.systemDefault()).toInstant());

Lowlife answered 8/12, 2017 at 17:39 Comment(0)

-2

I solved this question with solution below

  import org.joda.time.LocalDate;
  Date myDate = new Date();
  LocalDate localDate = LocalDate.fromDateFields(myDate);
  System.out.println("My date using Date" Nov 18 11:23:33 BRST 2016);
  System.out.println("My date using joda.time LocalTime" 2016-11-18);

In this case localDate print your date in this format "yyyy-MM-dd"

Cysticercoid answered 18/11, 2016 at 13:43 Comment(7)

Typo? Did you mean to pass date rather than data? – Dare 18/11, 2016 at 16:29

Please cite the documentation for that method. I do not see that method on the class doc for java.time.LocalDate. – Dare 18/11, 2016 at 16:32

My bad. My bad. I forgot copy the variable. – Cysticercoid 18/11, 2016 at 19:3

You can edit your Answer to correct the typo. And clarify the source of that method you used. Seems to be from Joda-Time, but this Question is about java.time.LocalDate. The Joda-Time project is now in maintenance mode, with the team advising migration to java.time. – Dare 19/11, 2016 at 1:17

Thanks @BasilBourque for your observation. In this case i used the class LocalDate of package: org.joda.time Fixing the answer I solved this issue with the solution below:

import org.joda.time.LocalDate Date myDate = new Date (); LocalDate localDate = LocalDate.fromDateFields (myDate);  System.out.println("My date using Date" Nov 18 11:23:33 BRST 2016); System.out.println("My date using joda.time LocalTime" 2016-11-18);

– Cysticercoid 21/11, 2016 at 11:44

I suggest this other answer available in this stack: #21242610 In this case was used the class of org.time.LocalDate. – Cysticercoid 21/11, 2016 at 12:5

The Joda-Time project is now in maintenance mode. Its team advises migration to the java.time classes built into Java 8 and later. For Java 6 & 7 use the ThreeTen-Backport project. – Dare 1/6, 2017 at 16:41

-5

You can convert the java.util.Date object into a String object, which will format the date as yyyy-mm-dd.

LocalDate has a parse method that will convert it to a LocalDate object. The string must represent a valid date and is parsed using DateTimeFormatter.ISO_LOCAL_DATE.

Date to LocalDate

LocalDate.parse(Date.toString())

Soneson answered 19/10, 2016 at 20:2 Comment(1)

You have obivously not tested your code suggestion, otherwise you would have seen an exception because java.time.LocalDate expects an ISO-formatted string, not the std-output of java.util.Date. Deserves a downvote, but today I have a good day ;-) The best answer here is given by Basil Bourque. – Handlebar 21/10, 2016 at 10:15

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++