This may be a failure of my understanding, but the comments in DateTimeZone.getOffsetFromLocal lead me to believe that if an ambiguous local time is given, the offset corresponding to the later of the two possible UTC instants will be returned - i.e. the greater offset.
This doesn't appear to tally with my experience. In fall 2009, America/Los_Angeles changed from -7 to -8 at 2am wall time on November 11. Thus 2am became 1am - so 1:30am is ambiguous. I would therefore expect that constructing a DateTime for November 11th, 1:30am would give an instant corresponding with the later value (i.e. 9:30am UTC). This appears not to be the case:
import org.joda.time.DateTime;
import org.joda.time.DateTimeZone;
public class TzTest {
public static void main(String[] args) throws Exception {
DateTimeZone zone = DateTimeZone.forID("America/Los_Angeles");
DateTime when1 = new DateTime(2009, 11, 1, 0, 30, 0, 0, zone);
DateTime when2 = new DateTime(2009, 11, 1, 1, 30, 0, 0, zone);
DateTime when3 = new DateTime(2009, 11, 1, 2, 30, 0, 0, zone);
System.out.println(when1);
System.out.println(when2);
System.out.println(when3);
}
}
Results:
2009-11-01T00:30:00.000-07:00 // Correct
2009-11-01T01:30:00.000-07:00 // Should be -08:00
2009-11-01T02:30:00.000-08:00 // Correct
Correction: it should be the smaller offset from UTC in absolute terms, as that means a later UTC value when it's subtracted from local time.
Fixed. The Javadoc was misleading previously as it implied the later. In fact the result for overlaps was undefined and varied by hemisphere. Now it returns the earlier instant for an overlap irrespective of hemisphere.
DateTimeZone.getOffsetFromLocal [2952991]
The behaviour during DST overlaps is now defined to always return the earlier instant which is normally known as daylight or summer time. Previously, the result varied by hemisphere. This affects the constructor of DateTime and other methods