The diff is 23 lines long, the vast majority of which is documentation: https://github.com/eggert/tz/commit/5b5b39dae16f787740b8c0d4...
In Cuba is skipping its November 1, 2026 clock change and staying on DST until 2027eggert
tz
C2014–2026
eggert / tz
tz
Time zone database and code
38Distinct people
46Mentions
1Explicit recommenders
1.9KGitHub stars
What to know before exploring
What it is
Time zone database and code
GitHub
Where it is used
The source check is incomplete. Verified examples will appear here.
What people are saying
I recommend anyone interested to look at some of the documentation done in the IANA timezone dataset (historical references of Finland shown here):…
Jhsto used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year46 dated mentions
Observed mentions: 2014-02-21 22:03:08 UTC to 2026-10-29 08:46:02 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 9 | 1 | 8 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
README for the tz distribution
“Where do I set the hands of the clock?” – Les Tremayne as The King
“Oh that – you can set them any place you want.” – Frank Baxter as The Scientist
(from the Bell System film “About Time”)
The Time Zone Database (called tz, tzdb or zoneinfo) contains code and
data that represent the history of local time for many representative
locations around the globe. It is updated periodically to reflect
changes made by political bodies to time zone boundaries, UTC offsets,
and daylight-saving rules.
See <https://data.iana.org/time-zones/tz-link.html> or the
file tz-link.html for how to acquire the code and data.
Once acquired, read the leading comments in the file ‘Makefile’
and make any changes needed to make things right for your system,
especially when using a platform other than current GNU/Linux.
Then run the following commands, substituting your desired
installation directory for ‘$HOME/tzdir’:
make TOPDIR="$HOME/tzdir" install
"$HOME/tzdir/usr/bin/zdump" -v America/Los_Angeles
See the file tz-how-to.html for examples of how to read the data files.
This database of historical local time information has several goals:
* Provide a compendium of data about the history of civil time that
is useful even if not 100% accurate.
* Give an idea of the variety of local time rules that have existed
in the past and thus may be expected in the future.
* Test the generality of the local time rule description system.
The information in the time zone data files is by no means authoritative;
fixes and enhancements are welcome. Please see the file CONTRIBUTING
for details.
Thanks to these Time Zone Caballeros who’ve made major contributions to the
time conversion package: Keith Bostic; Bob Devine; Paul Eggert; Robert Elz;
Guy Harris; Mark Horton; John Mackin; and Bradley White. Thanks also to
Michael Bloom, Art Neilson, Stephen Prince, John Sovereign, and Frank Wales
for testing work, and to Gwillim Law for checking local mean time data.
Thanks in particular to Arthur David Olson, the project’s founder and first
maintainer, to whom the time zone community owes the greatest debt of all.
None of them are responsible for remaining errors.
-----
This file is in the public domain, so clarified as of 2009-05-17 by
Arthur David Olson. The other files in this distribution are either
public domain or BSD licensed; see the file LICENSE for details.
Read the full README on GitHubWhat Hacker News says
46 sourcesThey're all over it before we hear about it:
3 days ago: https://github.com/eggert/tz/commit/5b5b39dae16f787740b8c0d4...
It's not even the latest change to the library!
In Cuba is skipping its November 1, 2026 clock change and staying on DST until 2027I don't really care how time is reckoned so long as there is some
agreement about it, but I object to being told that I am saving
daylight when my reason tells me that I am doing nothing of the kind.
I even object to the implication that I am wasting something
valuable if I stay in bed after the sun has risen. As an admirer
of moonlight I resent the bossy insistence of those who want to
reduce my time for enjoying it. At the back of the Daylight Saving
scheme I detect the bony, blue-fingered hand of Puritanism, eager
to push people into bed earlier, and get them up earlier, to make
them healthy, wealthy and wise in spite of themselves.
-- Robertson Davies, The diary of Samuel Marchbanks,
Clarke, Irwin (1947), XIX, Sunday
* https://
Read the rest
The East Kootenays still hasn't decided what timezone to align with. They used to align with Alberta (w/ daylight savings switching) as well. Then B.C. announced their change and the East Kootenays announced they were aligning to Pacific Daylight Time, which meant for the East Kootenays only uniquely "falling back" an hour a final time this fall. Then the East Kootenays rescinded that decision, and since then, Alberta has announced permanent daylight time. Now they need to decide which to align with.
The current plan is for the East Kootenays (America/Cranbrook) to "fall back" to PDT this fall, but IANA TZ database still hasn't made the update because of the uncertainty.
IANA revert: https://github.com/eggert/tz/commit/afcea8761543ac97aeee6399...
https://www.cbc.ca/news/canada/british-columbia/what-time-is...
In British Columbia, Time Zones, and Postgres> 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 -
In The surprising whimsy of the Time Zone DatabaseAmusing story of the chaos of timezones in Saudi Arabia and a man who made his own: https://archive.aramcoworld.com/issue/196902/dinner.at.when....
Linked from https://github.com/eggert/tz/blob/main/asia#L3818
In The surprising whimsy of the Time Zone DatabaseThat would provide the machine readable version... but not the human documentation of time. You wouldn't be able to debug the Moroccan Ramadan rule (which is provided as some elisp code) and its predictions for future changes.
Having it be managed by governments would mean that the whim of a politician could break things by changing the established name... say from "US/Pacific" to "USA/Pacific" or deciding by fiat to change the timezone for a political enclave within another one that doesn't have a TLD. ( https://github.com/eggert/tz/blob/main/northamerica#L821 )
This also describes the compromises in the design of the system to accurately record the time.
# From Paul Eggert (2026-03-07):
# The law says that 21 hours after the usual 2026-03-08 02:00 switch from
# PST to PDT, the next day inaugurates the new standard time Paci
Read the rest
fic Time,
# i.e., just one clock change but two name changes separated by 21 hours.
# PT, the obvious abbreviation for Pacific Time, is one letter too short
# to conform to TZDB’s (and POSIX’s) [-+[:alnum:]]{3,6} requirements.
# I asked the BC government for advice, with no response. For now, do this:
# 1. As a temporary hack, pretend that the BC law takes effect
# not on 2026-03-09 at 00:00, but on 2026-11-01 at 02:00.
# This pretense works around a limitation in CLDR v48.1 (2026-01-08),
# which would otherwise say the interval uses “Pacific Standard Time”.
# (Below, this temporary hack is marked “Temporary hack; see above.”)
# Strictly speaking this hack is incorrect since the interval uses
# standard time, but it does have the right UT offset and it
# works around the CLDR limitation. We should be able to remove
# the temporary hack after CLDR is fixed.
IANA tz (and POSIX) cannot add British Columbia's new Pacific Time (PT) timezone
3 points · Open discussionYes. https://en.wikipedia.org/wiki/Sandford_Fleming ( https://www.smithsonianmag.com/smithsonian-institution/sandf... )
> He promoted worldwide standard time zones, a prime meridian, and use of the 24-hour clock as key elements to communicating the accurate time, all of which influenced the creation of Coordinated Universal Time.
The one bit where this would be problematic would be "what day is it?" When does today become tomorrow?
There are a lot of systems that we've built that depend on that distinction. Things like business days and running end of day so that everything that happens on March 2nd is logged as March 2nd. I've encountered fun with Black Friday sales where the store is open over the midnight boundary and the backend system really wants today to be today rather than yesterday (sometimes this has involved unplugging a r
Read the rest
egister from the network so that it doesn't run end of day, running EOD on the store systems, and then plugging the register back in after it completes and then running a reconciliation.).
Other than that particular mess of banks and businesses... yea, running everything on UTC would be something nice in today's world.
---
This is also kind of what happens in China (with a complicated history). https://github.com/eggert/tz/blob/main/asia#L272
https://en.wikipedia.org/wiki/Time_in_China UTC+08:00 is observed throughout the country even though it spans about 60° of longitude.
---
Aside on the "changing clocks" and realizing my flexible schedule privilege at a company I worked at I switched my schedule from 8-4 to 9-5 with the change in daylight savings so that I maintained a consistent "this is the hour I wake up".
This change https://github.com/eggert/tz/commit/baea52df7ac9c4b53857556f... was a huge pain in my ass in 2013.
I was working in Libya on voter registration tools with the UN and the High National Election Commission. The government decided to not implement a planned TZ change, and didn't inform the public until the day of. Not the hardest thing we dealt with, that was a full country internet shutoff by a mob outside our data centre (https://www.bbc.com/news/world-africa-25481794). Sometimes the politics of a project are more complicated than the technology...
We did implement an all-SMS voter registration system, which was pretty cool. Hasn't been used much since, but it's all open source. https://github.com/hnec-vr
In How the tz database works (2020)I've found the comments in the database files (e.g. North America https://github.com/eggert/tz/blob/main/northamerica ) to be an interesting documentation of the history of the definition of time for various areas. For example, Indiana https://github.com/eggert/tz/blob/main/northamerica#L846
In How the tz database works (2020)Oh by the way, check this out, this is one of the news in 2025b tzdata:
# From Roozbeh Pournader (2025-03-18):
# ... the exact time of Iran's transition from +0400 to +0330 ... was Friday
# 1357/8/19 AP=1978-11-10. Here's a newspaper clip from the Ettela'at
# newspaper, dated 1357/8/14 AP=1978-11-05, translated from Persian
# (at https://w.wiki/DUEY):
# Following the government's decision about returning the official time
# to the previous status, the spokesperson for the Ministry of Energy
# announced today: At the hour 24 of Friday 19th of Aban (=1978-11-10),
# the country's time will be pulled back half an hour.
From https://github.com/eggert/tz/blob/main/asia#L1503.
Pretty sure we can find a lot more oddities that are way worse.
In How to Think About Time in ProgrammingThe reason the zones use city names is because city identity is far more stable than national or regional borders. Still, the system can gracefully handle deprecation of a zone name. If Paris is renamed NewNewYork by edict of some new global despot, the IANA will just alias the two names together.
See https://github.com/eggert/tz/blob/main/backward for all the deprecated zones.
In JavaScript Temporal is comingIf I understand [1] correctly, two new zones (or one new one and the old one) would be created in that case. E.g. if Strasbourg would be occupied by Germany in 2027, a new Europe/Strasbourg could be created which has the same rules as Europe/Paris until 2026, and the rules of Europe/Berlin as of 2027.
[1] https://en.wikipedia.org/wiki/Tz_database
--
By the way, I looked up the time zone in Crimea.
> On 29 March 2014, after annexation by Russia, Crimea switched from Eastern European Time (UTC+02:00) to Moscow Time (UTC+04:00 then, subsequently changed to UTC+03:00). [2]
Crimea has its own zone in the IANA database, Europe/Simferopol, which was updated in 2014 (and already existed before, as it already used Moscow time from 1994 to 1997). [3]
[2] https://en.wikipedia.org/wiki/Time_in_Ukraine
[3] https://lists.iana.org/hyperkitty/list/tz@ian
Read the rest
The most amusing tidbit about the tz database is that it contains an estimate of Big Bang, and it refuses to calculate timezone transitions occurring before the Big Bang.
The commit message at https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... says:
> For example, Glib computes Sao Paulo time stamps as if
Brazil's circa-1913 rules were still in effect. (Thanks to Leonardo Chiquitto for reporting the bug.) Work around the bug by not generating time stamps equal to -2**63. Come to think of it, time stamps before the Big Bang are physically suspect anyway, so don't generate time stamps before the Big Bang.
Soon afterwards, a separate commit disallowed leap seconds before the Big Bang.
In Australia/Lord_Howe is the weirdest timezoneShowing the 15 most recent of 46 sources. Enable JavaScript to search and browse every indexed mention.