[tz] Please remove tzdata2018f

[Florian Weimer]

* Paul Eggert:

> On 2/22/19 10:01 AM, Florian Weimer wrote:
>> Note that the more thorny issue is this one:
>>
>>   <https://bugs.openjdk.java.net/browse/JDK-8212684>
>>   <https://bugs.openjdk.java.net/browse/JDK-8212970>
>>
>> The current API follows POSIX and its requirements on hourly offsets,
>> and tzdata is no longer compatible with the POSIX specification of TZ
>> rules.
>
> As far as I know this is currently an issue only with America/Godthab,
> Asia/Jerusalem, and Pacific/Fiji, all of which use rules for future
> timestamps that cannot be expressed using POSIX TZ strings. I don't know
> what the various TZUpdater/JDK combinations do with this.
>
> This issue with non-POSIX TZ strings has been present since tzcode
> 2013e. It is not directly connected to the more-recent kerfuffles about
> negative DST (as POSIX allows negative DST) and about a 25:00
> time-of-day (as the current data's 25:00 can be simulated with a POSIX
> TZ string).
>
> Here are the TZ values in question. They use Internet RFC 8653 section
> 3.3.1's extensions to POSIX TZ strings.
>
> America/Godthab <-03>3<-02>,M3.5.0/-2,M10.5.0/-1
> Asia/Jerusalem IST-2IDT,M3.4.4/26,M10.5.0
> Pacific/Fiji <+12>-12<+13>,M11.1.0,M1.2.2/123

Ah, I was confused.  I mistakenly assumed that the issue with Japan
applied to an upcoming time zone changing during the Olympics.  But even
if it did, it would only be relevant during one year.

Since changing DST rules moves a country out of POSIX compliance anyway,
the present data (and any one-year exception) isn't a new problem for
POSIX.

Thanks,
Florian