2

首先，抱歉这么长。我可能不需要所有代码，但想确定一下。

其次，我的实际问题是，我做错了什么，还是 joda-time 库中的错误？

我正在尝试使用 joda-time (1.6.1) 来计算，然后格式化持续时间。

我目前正在使用Period，这可能是错误的选择。如果是，请告诉我。但是，即使这是错误的选择，我也很确定这不应该发生。

我正在初始化一个Period使用毫秒（以秒为单位的持续时间乘以 1000）。我正在使用，Period所以我可以格式化并打印它：

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());

我得到了下面的异常，并查看了源代码以确认循环。

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

期间（长）：

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);
}
4

2 回答 2

5

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 :

于 2010-09-11T13:29:31.840 回答
3

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.

于 2010-09-11T13:30:02.997 回答