> You need it to encode or decode past dates to unix time or other time standards.

Which you need to do if

> You do not need it to "interpret" past dates.

you want to interpret past dates. Mainly you need a historical record of the offsets. Or you're trading inaccuracy of duration measurement from one or two days out of the year to every day of the year by not keeping track of historical offsets or taking them into consideration.

It is absolutely not esoteric for a user to want to know, for example, an accurate duration measurement between a past departure time in one zone and a past arrival time in another zone. (inb4 the user is supposed to somehow anticipate all possible datetimes and calculate these durations in advance in case they need them)

> Combining these two concerns with insanely different scopes is precisely the issue with the tzdb.

I'm laughing so hard at what I just visualized. "Oh, no you only use this zone library for current times, use this other library for past times".

Then someone gets this crazy idea to use just one library and realizes it's quite ridiculous to need a DNS client to pull in the records when they have this other library that has the historical and current zones in a few text files. So then they drop the DNS client and just start using tzdb. It can even work for future dates and times too!

As soon as you create a timestamp, it becomes a recording that needs to take historical zone information into account when interpreting it.