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
