On Dec 3, 2019, at 1:14 AM, Mikhail Gribanov <mikhail.gribanov@gmail.com> wrote:

If possible, please mark these zones as inactive (if we assume that the information in them is correct) or delete them (because they are useless and nobody uses them).

To quote the tzdb's Theory file: ftp://ftp.iana.org/tz/tzdb-2018g/theory.html "The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone with a notable location and records all known clock transitions for that location. Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent. Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970." There's no notion of a zone being "inactive"; even if two different tzdb "timezones" (which I prefer to call "regions", so as not to confuse them with "traditional time zone[s]") now happen to be part of the same traditional time zone, that doesn't mean that one of them is now "inactive". The tzdb does not exist only to allow converting the *current* time, expressed as some form of universal time (e.g., non-leap seconds that have elapsed since January 1, 1970, 00:00:00 UTC), to a local wall clock time; it also exists to convert times in the *past*: $ ls -l /System/Library/Kernels/kernel -rwxr-xr-x 1 root wheel 15867112 Oct 12 00:09 /System/Library/Kernels/kernel to a wall-clock time. The "somewhat-arbitrary" cutoff is the origin of time stamps on UN*X systems, as well as time_t in the Microsoft C library; a program storing times in that format could store a date/time going back that far, and might want to convert it to local time, so differences dating back that far could be useful (and we're not in a position to say confidently that they're not useful). (And this is hardly unique to Ukraine - there are locations in the US that changed their "traditional time zone" in the 1990s.)

The main problem is that many third-party software offers these zones to choose from. What is wrong because these zones do not exist now.

No, it's wrong because software shouldn't offer tzdb IDs to choose from. If software can determine your location and find the appropriate tzdb ID for the location in a map, given the location, that's idea. (The software running on my machine can do that - *and* if it sees that the machine has moved across tzdb ID boundaries, it updates the current local time zone setting; yes, it even does that in running processes that don't have TZ set explicitly.) If not, then offering lists of cities, from which the user can select the nearest city, would work.