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

[roger riggs]

Hi Sherman,

Thanks for digging into the details and providing a sound rationale.

I agree with the conclusion.

Thanks, Roger


On 10/22/2013 12:16 AM, Xueming Shen wrote:
> 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
>
>
>