Why does tzdata generates periods based on the tz iana rules?

You can’t know yet. During the next year europe will get rid of DST. And only at the end of 2020, we will know if a state stays in “summer” or “winter” time.

Also, Belgium might perhaps to decide to leave EU until then and joins the Peoples Republic of China and join their timezone… Unlikely, but who knows?

The actual timezone is only known for events in the past.

I’m pretty sure someone else in this forum might be able to explain in more detail…

There has been a lot of discussion in the threads about introducing the time related modules Calendar, NaiveDateTime, Time, Date, etc…

I am aware of that, thank you for pointing that out; I posted this right before sleeping and my head was “too much in the code” and lost clarity.

Nevertheless tzdata allows you to compute a local date in the future (for example from a utc date) with the current known rules, even though there are chances that it will be incorrect (and it will certainly be for European countries):

{:ok, datetime, 0} = DateTime.from_iso8601("2019-03-29T00:00:00Z")
DateTime.shift_zone(datetime, "Europe/Brussels") |> IO.inspect()
# {:ok, #DateTime<2019-03-29 01:00:00+01:00 CET Europe/Brussels>}

{:ok, datetime, 0} = DateTime.from_iso8601("2019-04-02T00:00:00Z")
DateTime.shift_zone(datetime, "Europe/Brussels") |> IO.inspect()
# {:ok, #DateTime<2019-04-02 02:00:00+02:00 CEST Europe/Brussels>}

{:ok, datetime, 0} = DateTime.from_iso8601("2030-03-29T00:00:00Z")
DateTime.shift_zone(datetime, "Europe/Brussels") |> IO.inspect()
# {:ok, #DateTime<2030-03-29 01:00:00+01:00 CET Europe/Brussels>}

{:ok, datetime, 0} = DateTime.from_iso8601("2030-04-02T00:00:00Z")
DateTime.shift_zone(datetime, "Europe/Brussels") |> IO.inspect()
# {:ok, #DateTime<2030-04-02 02:00:00+02:00 CEST Europe/Brussels>}

Above in 2030 in Belgium, DST still applies according to tzdata (because tzdata ofc can’t predict the future).

Anyway, the question is why tzdata generates some kind of table with periods computed from the iana rules, as seen in the github link above. I think it does so also for past dates; so we can forget about dates in the future, because these dates cannot be guaranteed indeed from a UTC date as rules/laws are changing; it was a terrible reference for my question.

I think the data is precalculated to get faster runtime behavior. Other libraries in other languages are going the same way.
JS: Moment Timezone | Home
.NET: https://nodatime.org/tzvalidate/generate?version=2019c

The calculation for time zone states is not so simple as it looks at first sight. There are many edge cases and some strange rules in the IANA rule set.

You can compute dates in the future. But it is not guaranteed that this will be the correct date forever. The rules can change over time.