My approach :
// initailize date object
Date date = new Date();
// get time zone
ZoneId zoneId = ZoneId.of("Asia/Dubai");
// create zonedDateTime object
ZonedDateTime zdt = ZonedDateTime.ofInstant(date.toInstant(), zoneId);
// instant of zonedDateTime
Instant instant = zdt.toInstant();
// convert instant to specified zone
instant.atZone(zoneId);
// Get Local Date Time Object
LocalDateTime ldt = LocalDateTime.ofInstant(instant,zoneId);
//Convert it back to Date Object
Date dateFinal = java.util.Date.from(Instant.from(ldt.atZone(zoneId)));
Can anyone help me with conversion of timeZone Date object in Java 8
Date date = Fri Mar 31 16:10:13 IST.
Now I need to convert this Date to any given timeZone Date object
Desired result:
Date resultDate = Fri Mar 31 14:40:13 GST
Basically here I used (Asia/Dubai) Time Zone
But my result is: 2023-03-31T16:10:13.854+0530. I am getting the result in IST only. It’s not getting converted to (Asia/Dubai).
I have mentioned all the ways I have tried.
tl;dr
Core Concept:
java.util.Datedoes not have a time zone. TheDate#toStringmethod lies to you.If handed a legacy
java.util.Dateobject, immediately convert tojava.time.Instant.Then apply your desired time zone.
Use only java.time
Your date-time handling should involve only the java.time classes.
The date-time classes outside that package are now legacy, terribly flawed in poor design. The legacy classes were supplanted by java.time in JSR 310, implemented in Java 8+.
You said:
Did you mean
java.util.Dateorjava.sql.Date? Both are legacy.java.time.Instant. Both the legacy and modern classes represent a moment as seen with an offset from UTC of zero hours-minutes-seconds.java.time.LocalDate. The legacy class pretends to represent a date-only, but because of faulty design it actually contains a time-of-day and an assumption of an offset of zero. In contrast, the modern class truly represents a date-only, without time-of-day, and without time zone or offset.Instead use this code:
You said:
Good. A
ZoneIdis the modern way to represent a time zone. AndAsia/Dubai, inContinent/Regionis the correct naming for real time zones.You said:
Using our
Instantobject seen above, use this code:Both
instant&zdthere represent the same simultaneous moment, the same point on the timeline. But the latter is viewed through the wall-clock time used by people in a particular region.You said:
Yes, you can extract an
Instantfrom aZonedDateTime. But this code in unnecessary here as we already instantiate aInstantobject to capture the current moment.You said:
The problem here is that an
Instantobject, like all the java.time objects, is immutable. You can alter (“mutate”) the content of anInstantobject after its creation. That moment is frozen forever.Furthermore, calling
Instant#atZonereturns a fresh newZonedDateTimeobject. We saw just that in our code earlier above. Your code shown above ignores the newZonedDateTimeobject returned byatZone.You said:
Two problem here:
LocalDateTimefrom theZonedDateTimeinstantiated above.LocalDateTime ldt = zdt.toLocalDateTime() ;LocalDateTime, you are discarding valuable information: the time zone. So you are left with merely a date and a time-of-day. But such a value is inherently ambiguous. For example, if noon on January 23 this year, we do not know if you meant in noon in Tokyo Japan, noon in Toulouse France, or noon in Toledo Ohio US — three very different moments several hours apart.Tip: If you do not yet fully grok date-time handling, avoid using
LocalDateTime. In most business situations, we generally care about a moment, a specific point on the timeline.LocalDateTimedoes not fit that case.You said:
Two problems here:
java.util.Date.from( instant )as we already have anInstantin hand. Or, if we had just theZonedDateTimeseen above,java.util.Date.from( zdt.toInstant() ).Dateclasses like the plague. Ditto forCalendar,SimpleDateFormat, etc.Your title asks:
I do not understand what you mean. The
java.util.Dateclass represents a moment in UTC. It has no time zone.(Actually there is a time zone buried with its code, but this code is practically irrelevant, and represents another of those terrible design decisions found in the legacy date-time classes.)
You said:
Do not be fooled by the
java.util.Date#toStringmethod. That method unfortunately injects the JVM’s current default time zone while generating text. While well-intentioned, this creates the false illusion thatDateincludes a time zone in its meaning when in fact it is "in UTC" (has an offset from UTC of zero).