getOffset for ambiguous time range 3 messages
yoshito_umaoka@us.ibm.com <yoshito_umaoka@us.ibm.com> | Tue, Oct 30, 2007 at 7:16 AM | To: Markus Scherer <markus.icu@gmail.com> Cc: srloomis@us.ibm.com, emmo@us.ibm.com, Mark Davis <mark.davis@icu-project.org> | Hi Markus,
In ICU4J, I added an API - getOffsetFromLocale in BasicTimeZone (I'm still thinkin where the method resides - may move it up to TimeZone) in my own branch.
http://bugs.icu-project.org/trac/changeset/22807/icu4j/branches/yoshito/dfmtparse/src/com/ibm/icu/util/BasicTimeZone.java
I initially thought that we just need one flag to control the behavior - whether earlier iteration or later iteration. Then I found a very odd example - Daylight -> Standard, but positive offset change (because base offset is changed at the same time). For DateFormat parsing, we may already know the local wall time is STD or DST. In this case, we want to use one of them even DST -> STD is a positive offset change. To make the API to cover all the cases, I had to implement two levels of flags - DST or STD / former or latter.
When LOCAL_STD is set and the transition is either STD->DST or DST->STD, it always interpret time as standard time, no matter LOCAL_FORMER/LOCAL_LATTER is set. When LOCAL_FORMER is set and the transition is STD->STD or DST->DST, then it always interpret time as former one.
I'm not sure the way of specifying these options are OK for public API..
-Yoshito
|
|
Markus Scherer <markus.icu@gmail.com> | Wed, Nov 14, 2007 at 10:41 AM | To: yoshito_umaoka@us.ibm.com Cc: srloomis@us.ibm.com, emmo@us.ibm.com, Mark Davis <mark.davis@icu-project.org> | Hi Yoshito,
Sorry for the very late reply!
This sounds like it might be simpler to have an "enum" (simple "final int"s in Java) with 4 values rather than two boolean or dual-choice parameters.
markus
[Quoted text hidden] |
|
yoshito_umaoka@us.ibm.com <yoshito_umaoka@us.ibm.com> | Wed, Nov 28, 2007 at 2:56 PM | To: Markus Scherer <markus.icu@gmail.com> Cc: emmo@us.ibm.com, Mark Davis <mark.davis@icu-project.org>, srloomis@us.ibm.com | Hi Markus,
I got your point and I agree that we may want to simplify the options.
For this time, I already implemented like that way and had no time to improve the options, I will go for the current implementation. The API is marked as @internal because we cannot add any public APIs in maintenance releases. However, after once 3.8.1 is shipped, I will revisit this and clean up the options. For 4.0, I will post the updated API proposal in the design list and make the API public (@draft 4.0).
-Yoshito
|
|
|
|