diff options
| author | Elliott Hughes <enh@google.com> | 2010-02-05 17:36:23 -0800 |
|---|---|---|
| committer | Elliott Hughes <enh@google.com> | 2010-02-05 17:54:25 -0800 |
| commit | c3d6ff6b1639ef0ee19083ea23ceec0b442383ed (patch) | |
| tree | 5871f4b5eccb1cf1abbe1d5c73b260118fcc58d3 /vm/compiler/codegen | |
| parent | 55589b8ad1aa6b79ed9ebc31c78b16fb0c76d600 (diff) | |
| download | android_dalvik-c3d6ff6b1639ef0ee19083ea23ceec0b442383ed.tar.gz android_dalvik-c3d6ff6b1639ef0ee19083ea23ceec0b442383ed.tar.bz2 android_dalvik-c3d6ff6b1639ef0ee19083ea23ceec0b442383ed.zip | |
Fix a bug I introduced to SimpleTimeZone with my Calendar.setTimeZone fix.
Our implementations of SimpleTimeZone and Calendar became mutually recursive
for custom time zones when I changed GregorianCalendar.computeFields to use
TimeZone.inDaylightTime --- SimpleTimeZone's implementation of inDaylightTime
creates a GregorianCalendar leading to a stack overflow looking something
like this...
at java.util.SimpleTimeZone.inDaylightTime(SimpleTimeZone.java:599)
at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:595)
at java.util.Calendar.complete(Calendar.java:819)
at java.util.Calendar.setTimeInMillis(Calendar.java:1319)
at java.util.GregorianCalendar.<init>(GregorianCalendar.java:339)
at java.util.GregorianCalendar.<init>(GregorianCalendar.java:325)
at java.util.SimpleTimeZone.inDaylightTime(SimpleTimeZone.java:599)
I've cut the knot by introducing "Grego" from ICU4J, and rewriting our
SimpleTimeZone.inDaylightTime in the style of ICU4J's implementation.
Maybe we'll be using the ICU4J calendar implementation sooner than I thought!
Diffstat (limited to 'vm/compiler/codegen')
0 files changed, 0 insertions, 0 deletions