What is the difference between a joda Chronology and a DateTimeZone?

user_1681681 0
Viewed 184

In particular, why does the constructor for a timezone-aware LocalTime require a Chronology instead of a DateTimeZone?

    public LocalTime(
            int hourOfDay,
            int minuteOfHour,
            int secondOfMinute,
            int millisOfSecond,
            Chronology chronology)    // <--- this

Why can we not just pass a DateTimeZone to specify the timezone? What is the difference between Chronology and DateTimeZone -- they both seem to just be used to specify timezone here?

It just means I end up having to wrap any timezone with a call to ISOChronology.getInstance() which seems cumbersome:

new LocalTime(18, 0, 0, 0, ISOChronology.getInstance(DateTimeZone.forID("America/New_York")))
timezone jodatime java
1 Answers

TL;DR: In your particular example there is no difference. I could not find an example where there is any difference, though with serialization of a LocalTime there may be in corner cases. The time zone of the chronology is ignored.

Skimming through the source code of LocalTime revealed a couple of observations:

  • LocalTime always uses UTC time zone internally. So no matter which chronology or time zone you pass, you are not getting what I would call a timezone-aware LocalTime. So providing a LocalTime(int, int, int, int, DateTimeZone) constructor would have been meaingless.
  • The chronology is used by the readResolve method, a method used by deserialization. There’s a Javadoc comment stating Handle broken serialization from other tools. I don’t know what it means. It seems to me that all the code does is make sure that the chronology stored in the object uses UTC time zone. Any advantage over not storing any chronology at all is slipping me.

It just means I end up having to wrap any timezone with a call to ISOChronology.getInstance() which seems cumbersome:

new LocalTime(18, 0, 0, 0, ISOChronology.getInstance(DateTimeZone.forID("America/New_York")))

The LocalTime object ignores the time zone anyway. The documentation of the constructor you are using says:

Constructs an instance set to the specified time using the specified chronology, whose zone is ignored.

So I think you can just as well use:

new LocalTime(18, 0)

You may provide three or four arguments if you need to specify second and/or millisecond. The LocalTime class has a total of 13 constructors to choose from.

To demonstrate (and disappoint?):

    LocalTime timeInNewYork = new LocalTime(18, 0, 0, 0,
            ISOChronology.getInstance(DateTimeZone.forID("America/New_York")));
    System.out.println(timeInNewYork.getChronology().getZone());

Output:

UTC

To answer the question in your title more directly, the Chronology class is for handling different calendar systems like Islamic or Buddhist calendar, which is something different from what a DateTimeZone does. And also something that doesn’t immediately seem to be needed in the context of a LocalTime, so there’s good reason to ask your question.

A further observation is that java.time, the modern Java date and time API inspired by Joda-Time, completely separates the concepts of chronology and time zone. A java.time chronology does not include a time zone. Also a java.time LocalTime objects neither uses a chronology nor a time zone (except that its static now method very reasonably accepts a ZoneId argument; I consider this a different story).

How to solve?

So how do we create a timezone-aware LocalTime with Joda then?

Edit: How much sense would that make? For events that happen at a certain time every day in some time zone? Of course, if you are designing a calendar system where you need to store, say, an event that occurs every day at 16:00 in Santiago de Chile and another event that happens every day at 18:00 in New York, NY. You know, I don’t.

To answer, as far as I can figure out, you can’t. The local in LocalTime means without time zone (which isn’t obvious, but it’s so).

If it were me, I would store the time of day in a LocalTime and the time zone in a DateTimeZone separately. That would give you the data you require. You may wrap the two pieces into a class of your own, a Time or ZonedTime class, for example.

java.time offers an OffsetTime class, a time with an offset. So it’s not a time-zone aware time, only a UTC offset aware time. Don’t know if that would be of any help to you, just thought it was worth mentioning in case.

Links

user_57728820
Related