<i18n dev> TimeZone#setRawOffset problem?

[Yoshito Umaoka]

On 9/15/2014 5:59 PM, Aleksej Efimov wrote:
> Yoshito, I can explain such behavior only by this part of javadoc + 
> some calculations: Let's select the Asia/Yakutsk (please, refer to 
> tzdb rules in previous e-mail) as an example. The 'setRawOffset' 
> javadoc [1] says the following: "If an underlying TimeZone 
> implementation subclass supports historical GMT offset changes, the 
> specified GMT offset is set as the latest GMT offset and the 
> difference from the known latest GMT offset value is used to adjust 
> all historical GMT offset values." The latest known GMT offset is: 
> 9:00 = 32400 (let's count in seconds) New raw offset value (the value 
> set by your test program): 37800 The difference from the known latest 
> GMT offset value: 37800 - 32400 = 5400 Current DST offset (10:00 = 
> 36000 ) is adjusted with this constant: 36000 + 5400 = 41400 Please, 
> note that the 37800 is set as a last GMT offset and it will take 
> effect only on "2014 Oct 26". Other historical offsets will be 
> corrected with difference between latest tzdb offset and new offset 
> value = 5400. I think everything works as expected and not sure if it 
> is a JDK bug, maybe unclear documentation or something else. -Aleksej 
> [1] 
> http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#setRawOffset(int)

Thanks for clarification.

I would say the document simply spelled out the existing 
implementation's behavior (, and not what it should behave)... Anyway, 
it's not a critical problem - I even think the method (setRawOffset) 
should be harmful and deprecated.

(BTW, if this is the case, setRawOffset(int) only updates the base 
offset of date after year 2037 for some Brazilian zones?)

-Yoshito