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

[Xueming Shen]

On 10/22/2013 08:12 AM, Stephen Colebourne wrote:
> 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."
>

It is the fact everybody here already knew:-) There is no such thing called timezone
back then. As a matter of fact, it's theoretically impossible to have an accurate/correct
or say meaningful zdt for date/time before any tz even defined. You have to reasonably
"define" a zone offset for those date/time, if a zdt is really desired. Personally I believe
the location based solution is a reasonable approach, but I would just pick the "standard"
offset of that particular location, without seconds and even minutes, but I don't think
anyone will follow and build their application on my believe:-) LMT is tzdb's approach
to define the offset for this issue. Yes, as its theory claims, it's not really the factual
timezone offset back then and you should not bet your future on that. But, it's still a
database the industry follows and lots of platforms build their libraries on, especially
it is now officially maintained by a standard body. So I don't see a compelling reason
that java.time should just derives from it. Given the great flexibility of JSR310 tz data
provider framework:-) anyone actually can implement and replace the default tzdb
with whatever they believe to be more practical and sensible, if desired. So maybe
it's a reasonable decision to just leave the tzdb/LMT as is, for the default implementation.

That said, this issue probably deserves more discussions. How about change this
one to RFE (it is really not a bug at first place) and remove it from the jdk8 target
list and continue the discussion for a better alternative for the future release, even
the jdk8u, if we can reach a consensus?

-Sherman

> 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
>>
>>
>>