You need historic timezone information to interpret past dates, not just the current timezones.

You need it to encode or decode past dates to unix time or other time standards. You do not need it to "interpret" past dates.

Even then the tzdb only covers _offsets_ within a day. So even without it you can get an answer that is very close to the "correct" answer. For dates at that great of a remove the lack of accuracy to a precise second is rarely a problem.

I don't exactly need to schedule a remote video phone call with someone still using Double British Summer War Time. For those that do have this requirement they can use whatever specialty database they want.

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

	▲	dqv 2 hours ago \| parent [-]
		> 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.