StackOverflowError using joda-time new Period(long)

Question

First, sorry this is so long. I probably don't need all the code, but wanted to be sure.

Second, my actual question is, am I doing something wrong, or is this a bug in the joda-time library?

I'm trying to use joda-time (1.6.1) to calculate, then format time durations.

I'm currently using Period, which may be the wrong choice. Please let me know if it is. However, even if it is the wrong choice, I'm pretty sure this shouldn't happening.

I'm initialising a Period using milliseconds (by multiplying a duration in seconds by 1000). I'm using the Period so I can then format it and print it:

long durationLong = durationSec * 1000;
Period duration = new Period(durationLong);

PeriodFormatter daysHoursMinutes = new PeriodFormatterBuilder()
    .appendHours()
    .appendSeparator(":")
    .appendMinutes()
    .appendSeparator(":")
    .appendSeconds()
    .toFormatter();

String formattedString = daysHoursMinutes.print(callDuration.normalizedStandard());

I get the Exception below, and have looked through the source to confirm the loop.

Caused by: java.lang.StackOverflowError
    at java.util.Hashtable.get(Hashtable.java:274)
    at java.util.Properties.getProperty(Properties.java:177)
    at java.lang.System.getProperty(System.java:440)
    at java.lang.System.getProperty(System.java:412)
    at org.joda.time.DateTimeZone.getDefault(DateTimeZone.java:132)
    at org.joda.time.DateTimeZone.forID(DateTimeZone.java:190)
    at org.joda.time.DateTimeZone.getDefault(DateTimeZone.java:132)
    at org.joda.time.DateTimeZone.forID(DateTimeZone.java:190)

...snip (all the same)...

    at org.joda.time.DateTimeZone.getDefault(DateTimeZone.java:132)
    at org.joda.time.DateTimeZone.forID(DateTimeZone.java:190)
    at org.joda.time.DateTimeZone.getDefault(DateTimeZone.java:132)
    at org.joda.time.DateTimeZone.forID(Dat

Period(long):

public Period(long duration) {
    super(duration, null, null);
}

super(long, PeriodType, Chronology):

protected BasePeriod(long duration, PeriodType type, Chronology chrono) {
    super();
    type = checkPeriodType(type);
    chrono = DateTimeUtils.getChronology(chrono);
    iType = type;
    iValues = chrono.get(this, duration);
}

DateTimeUtils.getChronology(chrono):

public static final Chronology getChronology(Chronology chrono) {
    if (chrono == null) {
        return ISOChronology.getInstance();
    }
    return chrono;
}

ISOChronology.getInstance():

public static ISOChronology getInstance() {
    return getInstance(DateTimeZone.getDefault());
}

DateTimeZone.getDefault():

public static DateTimeZone getDefault() {
    DateTimeZone zone = cDefault;
    if (zone == null) {
        synchronized(DateTimeZone.class) {
            zone = cDefault;
            if (zone == null) {
                DateTimeZone temp = null;
                try {
                    try {
                        temp = forID(System.getProperty("user.timezone"));
                    } catch (RuntimeException ex) {
                        // ignored
                    }
                    if (temp == null) {
                        temp = forTimeZone(TimeZone.getDefault());
                    }
                } catch (IllegalArgumentException ex) {
                    // ignored
                }
                if (temp == null) {
                    temp = UTC;
                }
                cDefault = zone = temp;
            }
        }
    }
    return zone;
}

forID(String) calls getDefault(), which creates the loop:

 public static DateTimeZone forID(String id) {
    if (id == null) {
        return getDefault();
    }
    if (id.equals("UTC")) {
        return DateTimeZone.UTC;
    }
    DateTimeZone zone = cProvider.getZone(id);
    if (zone != null) {
        return zone;
    }
    if (id.startsWith("+") || id.startsWith("-")) {
        int offset = parseOffset(id);
        if (offset == 0L) {
            return DateTimeZone.UTC;
        } else {
            id = printOffset(offset);
            return fixedOffsetZone(id, offset);
        }
    }
    throw new IllegalArgumentException("The datetime zone id is not recognised: " + id);
}

Answer 1

As the looping part is only in the joda code, I would say that's a bug.

---

It has been corrected on the trunk and will be available in V2.0.

---

Resources :

• The reported bug

Answer 2

Looks like it's a bug in that it assumes the user.timezone property will have been set.

That's the way to get round it in this case - just make sure that user.timezone is set appropriately. It's a shame that you have to though.

Joda Time uses "null means default" in a lot of places - unfortunately, in my view. I prefer "null is invalid" usually. In Noda Time (a port of Joda Time to .NET) we're trying to get rid of a lot of this kind of thing - as well as preventing the default time zone from being as prevalent in the first place.