[themafia]

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]

> 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.

[shagie]

> It can even work for future dates and times too!

Morocco has some complex logic around Ramadan... which is a moveable festival.

https://github.com/eggert/tz/blob/main/africa#L854

    Rule Morocco 2026 only - Feb 15  3:00 -1:00 -
    Rule Morocco 2026 only - Mar 22  2:00 0 -
    Rule Morocco 2027 only - Feb  7  3:00 -1:00 -
    Rule Morocco 2027 only - Mar 14  2:00 0 -
    Rule Morocco 2028 only - Jan 23  3:00 -1:00 -
    Rule Morocco 2028 only - Mar  5  2:00 0 -
    Rule Morocco 2029 only - Jan 14  3:00 -1:00 -
    Rule Morocco 2029 only - Feb 18  2:00 0 -

[dqv]

Didn't know that it was moveable! It's actually a great example of why storing future datetimes in UTC is wrong. Future dates should always be stored in local time with appropriate zone information and then converted close to the "decision time". Otherwise, it may represent the wrong local time by the time the dated information is supposed to take effect!

[shagie]

Ramadan really moves around the calendar. From what I understand, summertime Ramadan can be quite challenging to fast from sunrise to sunset. https://www.bibalex.org/SCIplanet/en/Article/Details.aspx?id...

That's part of the reason that Morocco does a time shift during Ramadan - moving sunrise an hour later in the day so that there is more time before dawn to have breakfast. It's daylight savings but for the purpose of more pre-dawn time than afternoon-sun time.

https://www.moroccoworldnews.com/2026/02/278108/morocco-to-r...

> Rabat – The Ministry of Digital Transition has announced that Morocco will suspend daylight saving time and return to GMT on Sunday, February 15 at 3 a.m for Ramadan 2026.

> Astronomical calculations expect Ramadan to begin on February 19 in Morocco. The Ministry of Islamic Affairs will confirm the official starting date after the sighting of the crescent moon.

> Morocco suspends daylight saving time exclusively for the holy month of Ramadan, as it affects the fasting time.

> The ministry emphasized that 60 minutes will be added to the official time at 2 a.m. on Sunday, March 22, following Ramadan.

> ...

> The North African country decided to adopt the daylight saving measure in 2008 during the summer season. The decision’s goal is to increase competitiveness of the national economy through reducing energy consumption and also the time difference between the country and its regional and international trading partners.

> Under the measure, Morocco switched the clock every summer to DST, GMT+1, and returned to the old standard time, GMT, for a period when Ramadan fell in the summer.

> In October 2018, however, the Moroccan government adopted Draft Decree 2.18.855, adding 60 minutes to the standard time in the country year-round.

> The decision stirred controversy and frustration, with Moroccans protesting the move. But it has since become a normal part of Morocco’s preparation for Ramadan.