Convert XMLGregorianCalendar to OffsetDateTime

I want to convert from XMLGregorianCalendar to OffsetDateTime. Is this possible?

You can convert an XMLGregorianCalendar to a GregorianCalender, then to a ZonedDateTime, and then to an OffsetDateTime. Why do you want an OffsetDateTime by the way, and not a ZonedDateTime or an Instant?

Ok thanks, I will try this route.

I need it because I am working with code that is not from me and OffsetDateTime is expected there... I must admit I am also a little bit confused why there are that many classes related to date and time. Is there any recommendation to which classes should be used if one would start from scratch implementing date and time functionality?

Most of the time you will want to use java.time.LocalDateTime, java.time.LocalDate and java.time.LocalTime. When you have to interact with other systems, or need an exact moment in time for any other reason, you would use java.time.ZonedDateTime or java.time.Instant. Avoid java.time.OffsetDateTime when you can, because it gives people the false idea they're dealing with time zones correctly.

Other useful classes are:

java.time.Duration

java.time.Period

java.time.Year

java.time.Month

java.time.YearMonth

java.time.MonthDay

java.time.DayOfWeek

java.time.temporal.ChronoUnit

java.time.temporal.ChronoField

java.time.temporal.IsoFields

java.time.temporal.WeekFields

java.time.temporal.TemporalQueries

java.time.temporal.TemporalAdjusters

java.time.format.DateTimeFormatter

Avoid ALL classes that deal with dates and times that are not from a package that start with java.time, with the possible exception of java.text.SimpleDateFormat (but prefer java.time.format.DateTimeFormatter).

Thank you for the info. You mentioned that OffsetDateTime does not work correctly with time zones? What exactly is it that is not working?

It's not that it doesn't work correctly, it just doesn't have anything to do with time zones. UTC+2 for instance, is not a time zone. There are time zones in which for most or all of the year it will be two hours later than UTC, but UTC+2 itself doesn't say which zones those are.

An example: Europe/Amsterdam is a time zone. It contains the date and time rules for the Netherlands. In the summer, it's equal to UTC+2. In the winter, it's equal to UTC+1. As you can see, you can't in general say that an OffsetDateTime reliably describes the date and time rules for certain geographical locations. ZonedDateTime does.

If you give me a ZonedDateTime, I can retrieve a local date and time from it without problems. If you give me an OffsetDateTime and ask me for a local date and time, I will ask you "a local time where?".

Very good explanation, I see your point.

I agree that ZonedDateTime is more explicit but one could argue that it's mixing concerns, overloading a single data element to include location information. It also requires complex time zone rules to convert into an Instant.

OffsetDateTime is trivial to convert into an Instant, and it is trivial to convert into a single LocalDateTime, that of the origin. The local time (respective of where/when the timestamp was generated) is just the timestamp without offset, no time zone rules required.

Welcome to CodeRanch!

I'm not saying there's no scenario where OffsetDateTime is useful, but I can't think of any where either LocalDateTime, ZonedDateTime or Instant isn't more appropriate.

LocalDateTime will do pretty much everything you might need OffsetDateTime for, except when you need an exact moment in time.

You only ever need an exact moment in time when you want to exchange data between two different systems, and even then LocalDateTime will do (if they're calculated relative to UTC), if you don't want to use Instant.

The only time I can think of where you really want to use OffsetDateTime is when you have a functional requirement to display the offset to the user.

Please let me know if you have a good use case that I haven't thought of.

Jesse Hautala wrote:I agree that ZonedDateTime is more explicit but one could argue that it's mixing concerns, overloading a single data element to include location information.

On the other hand, a time (13:38, say) is meaningless on its own. (Same goes for date/time.) For it to mean anything practical, it must be interpreted in the context of a "location". The location may be implicit (i.e. "at my house") or it may be specified in some other way.

If Concern A is incomplete without the aid of Concern B, then Concern A is not really a "concern" at all in terms of data design.

However both OffsetDateTime and ZonedDateTime provide a "location". The first specifies the location to be "somewhere where the offset from UTC is X hours" and the second specifies it to be "somewhere in a legally defined timezone T". Which of them you choose to use depends on how the associated "location" is to be used. For example "1970-01-06 13:38:06 UTC+1" tells you that the time is one hour later than UTC. If that's all you need, then you're fine. If you started with the fact that the time was relevant to London, England, then you would need to use knowledge of the history of London's timezone to tell you that UTC+1 is the appropriate offset. So it depends on your requirements.

I once worked on a Microsoft system which didn't know about timezone history. It just assumed that last year's DST rules were the same as the current rules. So in the year when DST was extended for an extra three weeks in the fall, the saved timestamps for those three weeks in the previous year were all now off by an hour. That of course was because the implicit "location" information for those timestamps was insufficient. In the absence of timezone information that problem could have been solved by appending the UTC offset to the timestamps, but that wasn't part of the language design.

I am assuming that your XMLGregorianCalendar holds a full date (year, month and day of month), a time of day (at least hour and minute) and a UTC offset (called timezone in the XML parlance) (each element is optional in XMLGregorianCalendar, but all are needed for OffsetDateTime). I am further assuming that your time of day has not got more than 9 decimals on the seconds (nanosecond precision). For example.
XMLGregorianCalendar xgc = DatatypeFactory.newInstance() .newXMLGregorianCalendar("2019-03-31T13:34:00+02:00");
There are some ways to go, each with their pros and cons.

Convert via String: I’d be tempted to do:
OffsetDateTime odt = OffsetDateTime.parse(xgc.toString()); System.out.println(odt);
Output:
2019-03-31T13:34+02:00
Pros: it’s short and hardly gives any surprises. Con: to me it feels like a waste formatting into a string and parsing back.

Others have already mentioned converting via GregorianCalendar and ZonedDateTime:
OffsetDateTime odt = xgc.toGregorianCalendar() .toZonedDateTime() .toOffsetDateTime();
Pro: it’s sort of the official conversion. Con: it’s longer.

If you want it complicated, you may also convert via integers, only included for completeness:
long offsetSeconds = Duration.ofMinutes(xgc.getTimezone()).toSeconds(); ZoneOffset offset = ZoneOffset.ofTotalSeconds(Math.toIntExact(offsetSeconds)); BigDecimal fractionalSecond = xgc.getFractionalSecond(); int nanos = fractionalSecond == null ? 0 : fractionalSecond.multiply(BigDecimal.valueOf(1_000_000_000)).intValueExact(); OffsetDateTime odt = OffsetDateTime.of(xgc.getYear(), xgc.getMonth(), xgc.getDay(), xgc.getHour(), xgc.getMinute(), xgc.getSecond(), nanos, offset);
Cons: it’s long, hard to read and easy to get wrong. If there is a pro, then: it’s the direct conversion.