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

Questions / Help
, , , , ,
1

Correct me if I’m wrong: the tzdata library seems to generate a huge number of periods based on tz iana zone rules.

You can see the module attribute in the first few lines of this module which seems to indicate that (and all the calc_periods functions):

So maybe really dumb question: why isn’t it possible to simply use the rules in order to have the correct local date?

For example, in Belgium, 28th January 2030, at 16:30 UTC will be 17:30 local time (gmt+1) according to the iana tz rule data.

Not sure what’s going on. Any idea?

2

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…

3 Likes
3

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.

4

I think the data is precalculated to get faster runtime behavior. Other libraries in other languages are going the same way.
JS: https://momentjs.com/timezone/
.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.

2 Likes