If I compare two DateTime with two different time zone, there is a problem, or I should make him in the same time zone ?
Example :
DateTimeZone a = new DateTimeZone("Pacific/Kiritimati");
DateTimeZone b = new DateTimeZone("Pacific/Gambier");
DateTime dateOne = new DateTime(a);
DateTime dateTwo = new DateTime(b);
if (dateOne.compareTO(dateTwo) == 0) {
// yes
} else {
// no
}
Thnak you. (sorry for my bad english)
On
The Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes.
You can indeed compare date-time objects of different time zones. Internally the moment is calculated as a number of seconds (plus fractional second) since the epoch of 1970-01-01T00:00:00Z. While the wall-clock time appears differently per the assigned time zone, think of their underlying meaning being a point on the timeline in UTC. Therefore any pair of date-time objects can easily be compared.
In java.time we use the ZonedDateTime for this work. This class offers isEqual, isBefore, and isAfter methods for comparison.
ZoneId zP_K = ZoneId.of( "Pacific/Kiritimati" ) ;
ZoneId zP_G = ZoneId.of( "Pacific/Gambier" ) ;
Instant instant = Instant.now() ; // Current moment in UTC, with resolution up to nanoseconds.
ZonedDateTime zdtP_K = instant.atZone( zP_K ) ;
ZonedDateTime zdtP_G = instant.atZone( zP_G ) ;
Boolean sameMoment = zdtP_K.isEqual( zdtP_G ) ; // Or `isBefore` or `isAfter`.
See this code run live at IdeOne.com.
instant.toString(): 2017-06-15T12:53:35.276Z
zdtP_K.toString(): 2017-06-16T02:53:35.276+14:00[Pacific/Kiritimati]
zdtP_G.toString(): 2017-06-15T03:53:35.276-09:00[Pacific/Gambier]
sameMoment: true
Tip: Do most of your thinking, your business logic, your logging, and your data exchange/storage all in UTC. Think of UTC as The One True Time™ with other zones being mere variations. Apply a time zone only where required by the business logic or for presentation to the user. Forget about your own parochial time zone while wearing your Programmer At Work hat.
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?
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.
People always have confusion about dates and timezones. A date (or a time, or datetime) is a specific instant in time. This instant is the same in all the Universe, so it is independent from timezone, and it is usually represented as UTC (Universal Time) or Z (Zulu time). Timzone is a modification of UTC to show relative solar time for this specific zone in Earth. By setting the timezone, you're just telling that this datetime is relative to this specific timezone, but internally it will be still represented as UTC. In this case, they should be different if the timezones have a different UTC offset.