I want to calculate time in Asia/Dubai timezone from the time of Asia/Kolkata using java 8 Date Time API -

 zoneid dubai = zoneid.of("asia/dubai");  localdate localdate = localdate.now();  localtime localtime = localtime.now();  zoneddatetime zoneddatetime = zoneddatetime.of(localdate, localtime, dubai); system.out.println("dubai tiime:"+zoneddatetime); 

above code still printing time of current zone (i.e asia/kolkata)

also tried following code achieve same printing time in current zone(asia/kolkata):

zoneoffset offset = zoneoffset.of("+04:00"); localdatetime localdatetime = localdatetime.now(); offsetdatetime plusfour = offsetdatetime.of(localdatetime, offset); system.out.println("dubai time :"+plusfour); 

i unable figure out why not providing desired result.

the answer kokorin correct. here's bit more discussion.

problems

when called now method , passed no arguments, failed specify time zone. in omission, java.time silently applied jvm’s current default time zone in determining current local time , current local date.

you claim jvm’s current default time zone asia/kolkata (india time). if when ran code 15:30 time in office, code saying “let's take 15:30 , use input represent wall-clock time in dubai”. while current moment in dubai 14:00 (an hour , half closer utc india presume, not sure), created date-time hour , half in dubai’s future: 15:30.

when passed dubai in line zoneddatetime.of( localdate, localtime, dubai ) assumed asking adjustment between time zones. in fact assigning time zone plain (“local”) date , time had no time zone @ all. 3 of local… classes store no time zone internally; purpose ignore time zone. code did not match intentions.

note how in revision code pass zoneid object both now methods. solve problem.

    zoneid dubai = zoneid.of ( "asia/dubai" );     localdate localdate = localdate.now ( dubai );       localtime localtime = localtime.now ( dubai ); // capturing `14:00` in dubai rather than `15:30` in india in version of code.     zoneddatetime zoneddatetime = zoneddatetime.of ( localdate , localtime , dubai );     system.out.println ( "dubai tiime:" + zoneddatetime ); 

but still bad code. if pair of .now methods called on stroke of midnight, have wrong information (off 24 hours).

solutions

instead should capture current moment atomically. either user kokorin's code, or use code shown next.

an instant moment on timeline in utc resolution of nanoseconds.

instant instant = instant.now(); zoneid zoneid_dubai = zoneid.of( "asia/dubai" ); zoneddatetime zdt_dubai = zoneddatetime.ofinstant( instant , zoneid_dubai ); 

as shortcut, call static method zoneddatetime.now.

zoneddatetime zdt_dubai = zoneddatetime.now( zoneid_dubai ); 

to see same moment own wall-clock time, adjust india time.

zoneddatetime zdt_kolkata = zdt_dubai.withzonesameinstant( zoneid.of( "asia/kolkata" ) ); 

big tip: always pass optional time zone arguments. while tremendously respect work went java.time, consider making time zone arguments optional on various methods design flaw. silent implicit application of jvm’s current default time zone easy trap fall many programmers. way, ditto locale, specify.

another tip: think, work, , store in utc. programmer must learn think in utc, head out of “my time in kolkata” , “their time in dubai”. drive crazy , make brain hurt. while programming, know the 1 true time utc. other dubai/kolkata/montréal/auckland times smoke , mirrors, mere illusions. use instant class in of code, make “go to” class when doing date-time work (only apply time zone display user). use utc in database. logging in utc. keep servers on utc (or iceland) time zone. use utc when serializing date-time values storage or in data-exchange (and use iso 8601 formats btw). keep clock on desk or screen displaying utc. later, when go home work, can slip own local "india time" thinking.