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

[Stephen Colebourne]

The Theory file in TZDB defines what LMT is and how it will be treated
https://github.com/eggert/tz/blob/master/Theory#L352

"In short, many, perhaps most, of the tz database's pre-1970 and
future time stamps are either wrong or misleading.  Any attempt to
pass the tz database off as the definition of time should be
unacceptable to anybody who cares about the facts.  In particular, the
tz database's LMT offsets should not be considered meaningful, and
should not prompt creation of zones merely because two locations
differ in LMT or transitioned to standard time at different dates."

What this means in practice is that LMT values have been and will be
changed on a whim, with absolutely no rationale for the change.

In practical terms, this means that a user of JSR-310 who creates a
ZonedDateTime representing a date in 1800 will see an LMT offset
measured in seconds, such as +01:32:29. When the TZDB is updated, this
offset may change, and there will be no valid rationale for the
change. That randomness of change will be a major cause of complaint.

In addition, I know from Joda-Time that users do not like these weird
LMT offsets in the first place. They would much prefer something
matching TimeZone.

My proposal to base the LMT value on 1970-2010 is practical and
sensible, but it is not the only choice.

A fixed 1900 cutoff date for ZoneId could also be acceptable (matching
TimeZone). Obviously some LMT will be exposed, but the problem would
be no worse than today. I am concerned with choosing today's offset
for the past however because that makes the application code very
brittle.

Arguing that we are followig the "standard" is not sensible when the
standard's authors tell you not to use that feature!

TimeZone already forks the TZDB, so we are not in new territory here.

Keeping JSR-310 using full TZDB LMT is far too risky given the
personal intentions of the TZDB maintainer wrt this data.
Stephen




On 22 October 2013 05:16, Xueming Shen <xueming.shen at oracle.com> 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
>
>
>