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.
See JSR 310 issue #332; https://github.com/ThreeTen/threeten/issues/332
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.
See JSR 310 issue #332; https://github.com/ThreeTen/threeten/issues/332
- relates to
-
JDK-8272289 Incorrect historical timezone for Europe/Paris
-
- Open
-