[threeten-dev] JDK-8024267 Stop using LMT for time-zones

[Xueming Shen]

Hi Stephen,

The current j.u.TimeZone implementation DOES use LMT. If the LMT is defined/used cross
the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example the offset for
Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the  LMT 10.34.36. Yes, if the
LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ.

So if the LMT is removed from the JSR310 zdt, inevitably we are going to have problem to
handle those date/time that fall into the period that uses LMT (after 1900.11) when converting
between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can remove the LMT
from the j.u.TimeZone for obvious compatibility reason. Sure, arguably because the
j.u.Timezone 1900.1.1 cutoff, we are having this problem already for date/time before the
1900 cutoff, but the removal is just to make thing worse.

As you suggested in the bug report, the problem is what to replace the LMT with. Honestly
I don't think any proposed alternative is better than the LMT (basically it's the tzdb's solution
for this unsolvable problem, what offset to use for that particular zone before any timezone
even get defined for that area). And what you're proposing basically is to fork the tzdb for
that part of date/time, replacing the location-based LMT with your own algorithm, for
non-convincing reason. Yes, the LMT is not ideal, but "to calculate and use a longest standard
used between 1970 and 2010" really does not make thing any better. While it's true that it's
"simple and deterministic", but it's still not correct at all for that period of time. The cost is to
fork the standard tzdb data and walk away from our "standard based" design principal for
timezone data. I agree the choice of the "location" for some particular zones might not be
ideal/correct/reasonable, but I don't think this is a big enough issue for the cost of forking
from the tzdb data for Java date/time.

I would suggest to simply keep the LMT asis, and close this RFE/bug, at least for now.

Thanks,
Sherman