Stop using LMT for time-zones

[jodastephen]

LMT is the offset specified in the tzdb data for times before time-zones began. It is derived from the lat/lon of the city named in the the time-zone ID. It is measured to the nearest second, not minute, so often sticks out like a sore thumb in the data.

The current TimeZone code does not use LMT. Joda-Time does, as does JSR-310. This is wrong.

Recent discussion on the tzdb mailing list has indicated that the data is not properly maintained or reliably linked to the city of the zone ID. It is also relatively meaningless, being a notional value for a single city within a large region.

Removing LMT is a good thing.

The problem is what to replace it with. Options:

• throw errors for ZDT before time-zones began (not acceptable I think)
• calculate an LMT equivalent ourselves (so that it at least is accurate, even if still not useful)
• calculate an alternative

My preference is to perform a calculation for each zone ID that evaluates the standard offset for the period 1970 to 2010, selecting the offset which is used for the longest period of time. This is simple and deterministic, and will produce results that make some sense.

[RogerRiggs]

Mirror JBS issue is: 8024267

[jodastephen]

Just to note that I don't know where this code is anymore, and for me to fix it will be tricky (as getting anything setup on Windows is hard). This must be fixed however.

[jodastephen]

ZoneRules documentation change:

+ * <p>
+ * Implementations should provide an offset for all input {@code LocalDateTime}
+ * and {@code Instant} values. It should be noted that offsets for dates in the
+ * future are generally speculation, while offsets before the near past are
+ * typically guesswork.
+ * <p>
+ * For example, the standard IANA time-zone rule database only aims to provide accurate
+ * offsets from 1970 onwards. Before that, the quality of the data varies considerably.
+ * For instants even further in the past, the concept of offsets and indeed GMT, did
+ * not exist. As such, the returned offset from the rules will be entirely fictional,
+ * although implementations should ensure it makes some logical sense.

[RogerRiggs]

Refer to Bugs.openjdk.java.net 8024267 for fix in future release.