One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Tom – WB8LCD and articles are submitted by cabinet members.
Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.
You can receive the Journal and other Ohio Section news by joining the mailing list Tom has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!
If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.
Now without further ado…
Read the full edition at:
THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net
Hey gang,
Time. We all use it. Most states change it twice a year. We all have our devices to keep track of it. Some are a little too proud of their device – ‘my WWV synced clock…’ I’ve discussed WWV in the past when it was on the chopping block for the national budget. Thankfully, that didn’t happen. As hams, we coordinate time with other operators. Nets that cross multiple time zones include Universal Coordinated Time (UTC) in announcements. This time, it’s not so much about having the correct time, rather how do computing devices know when they should change the time? I learned there’s one guy that makes sure devices know in what time zone they’re located.
I wondered: who maintains the time zone data on computing systems? Updating Linux systems would occasionally include the “tzdata” and accompanying packages. Well, someone changed their standard to daylight saving cutover again. Yes, it is “daylight saving time” though everyone says “daylight savings time.” Also wondered: what’s the difference when configuring a system’s time zone to be “US/Eastern” versus “America/New_York” or “America/Detroit?” For whatever reason, never bothered to look into it any further. That was until Paul, a co-worker of mine, was talking about a post he had seen describing one guy whom maintains the time zone database. That post is authored by Daniel Rosehill, who originally made a YouTube video about the subject. Daniel’s post is where I began exploring the topic further.
In a non-technical sense, time zones are political. Sure, it starts out with the prime meridian and count consistent offsets from there. Adopting and when to adjust time is left to the state. Most of Arizona is on standard time all year long. Some AZ cities decided to stay on mountain time or pacific time, adjusting when those zones change from standard to daylight saving. Closer to home, Indiana cities that are suburbs of Chicago adjust to central time while the remainder of the state uses eastern. Despite what our terrible media says, there are other conflicts, wars, crisis, clashes, and uprisings going on right now. To say that time zones are not important, try selecting the wrong time zone in a territory that’s in conflict with another territory or a countries time zone that has been deleted as punishment due to a historical event.
The “tz database” is a collaborative effort of information gathered by enthusiasts, done as a hobby or maybe in-conjunction with their job. This database is intended to be used with computer systems, programs and operating systems. The tz database definition of a time zone is “where clocks have agreed since 1970” (theory.html in source). If all clocks in a time zone have agreed since 1970, don’t include more than one zone or locale – even if some disagreed before 1970. The database attempts to record historical time zone and civil changes since 1970. 1970 is also important because it is the UNIX Epoch time (number of seconds that have elapsed since the arbitrary time of 00:00 UTC on 1/1/1970). Time zone data rules before 1970 are “best effort” which may identify a region but not necessary be correct for the entire region.
ICANN organizationally backs the tz database. ICANN approves top-level domains (.com, .net, .org, .io, .edu, .club, .info, .radio, etc.) and other Internet functions is the same group responsible for IANA. IANA oversees IP address allocation, Domain Name System (DNS), as well as other symbols, protocols, and Internet numbers. One guy is the editor and decision maker. His name is Paul Eggert. Paul works as a computer scientist and instructor in UCLA’s Computer Science department. He dedicates his time to maintaining the global time zone system. Eggert also designed the uniform naming convention for time zone locales, such as America/New_York and Europe/Paris.
Comments in source data files read like the history of the world’s stance on time. Referencing articles and texts used in decision making forming their time zone rules. This, well before Google Earth, where locations of importance only could be estimated in other parts of the world by utilizing such ancient technologies called a map or by calling someone on the telephone. States will arbitrarily decide they had enough of summer and change clocks one month earlier than expected (Jordan). Warlords, dictators take out anger on time and decide to change time zones with only four days’ notice – mostly in Africa.
These rules set time and shift standard to daylight saving (and back) on the correct date and time. They contain rules regarding leap seconds and other historical changes used in calculating time zone conversions. A program that can do such a conversion would know March 25, 2022 at 3pm in Ohio (EDT -4) is March 25, 2022 at 4am in Tokyo – which is still on standard time (JST +9). The same day in 1999, both time zones used standard time. Meaning March 25, 1999 at 3pm (EST -5) was March 25, 1999 at 5am in Tokyo.
Why the difference between America/New_York and America/Detroit? Today, both cities observe changing their clocks at the same time. Differences are of historical significance. Detroit has made many changes to time: 28 minus off central time in the 1900’s. Adopted central time in 1905. Michigan did not observe daylight saving time in 1967 like the rest of the US, it decided to begin DST on June 14 at 00:01. A vote in 1968 narrowly repealed DST to take effect in 1969. Observed DST, again, starting in 1973, however changed late in 1975.
New York (City), is the standard for eastern time by which most US states agree. In 1833, New York City Hall time was 3 minutes 58.4 seconds fast of eastern time. Today, selecting either New_York or Detroit will change the time when expected. Comparing historical time is the issue. Ohio’s time has followed that of New York City. All of this is documented in the tz data source code comments for northamerica with accompanying rules written to account for these changes. Selecting GMT-4 would always be 4 hours off GMT all-year round. The appropriate system section for Ohio would be America/New_York. US/Eastern is a link to America/New_York, which either will work though US/Eastern is considered deprecated.
Should legislation, which has already passed the Senate, making daylight saving time permanent, this would create another set of rules for all U.S. locales reflecting this change. Additional rules would be needed for any locales that decide not to adopt the legislation or decide to recognize the change on a different date.
The database is centralized and developed for Unix and Unix-like systems, including Linux and Mac-based computers. Most Internet users don’t understand Linux is quite important in the computing world. While Linux lags behind in the desktop operating system market, favored by hard-core computer enthusiasts. In the server world, Linux dominates, even on cloud infrastructure. Windows systems utilize a mapping between Microsoft Windows time zone IDs and the tz database. This is not perfect as Windows implements less time zones than are present in the database. Changes and releases to the tz database are documented at the tz mailing list.
Most Linux systems store time zone data located in the directory: /usr/share/zoneinfo. Those files are compiled and not human-readable but the operating system uses those files to shift time and for time zone conversions. The Linux command timedatectl will display system time information: local time, UTC, RTC (hardware clock), time zone, and is time synchronized with an NTP server (Network Time Protocol, usually servers on the Internet). It is standard for *nix systems to store the hardware clock in UTC. Philosophy being it is best not to mess with the hardware clock and do the conversion visually for the user. This is noticed on dual boot Linux and Windows systems. Linux will be the correct time but Windows will display (as of this writing) 4-hours fast.
Real Time Clocks are dumb clocks. They have no ability to adjust for time changes on their own. It is understood in the computing world that external facilitates manage the RTC – most often the Operating System – will adjust the system clock with the help of the tz database. Much like an alarm clock, microwave, or wall-clock that need manual adjusting when the time changes or due to drift.
Think of all the systems, devices, and things that rely on time. The tz database is one, very small, piece of technology which hundreds of millions of devices rely. Daniel pointed out in his write up, think of all the startup companies and dubious technologies that claim to change air water into oil, only to vanish into oblivion within a few years. The tz database won’t vanish, because it can’t. Everything relies on this database at the bottom of a very large technology stack.
I’ve seen programs written where developers implement code to account for changes in time zones. Don’t. Just don’t. The best way for a coder or database administrator to deal with time zones is not to deal with time zones. Let the system handle time or include time zone libraries in the project. Where there are time zone issues to fix, there will be more.
The results are bad and potentially catastrophic when developers attempt to account for time zone changes. It confuses users of the system: why is it changing the time using this one function of the program? The answer is usually something like: the developer stored time in local time instead of UTC, they recognized when this information is sent to a different location across time zones, time would have to be adjusted. However, they implemented hard-coded logic which no longer applies because the state recently changed their rules. Those rules are now wrong and nobody knew or remembered they were there in code.
Upstream systems start making incorrect decisions based on the garbage data received as a result of bugs like these. For example, a customer is charged interest on a payment that was recorded as late but wasn’t actually late. It continues to roll downhill from there.
As Daniel points out, these high-stakes deliberations represent a near Y2K meltdown that must be averted. Every. Time. A single erroneous key stroke could instantly change EST to CST or PST. Magnify the example scenario above by millions of systems which all have the wrong time. Think of all the confusion, missed meetings, missed scheduled jobs, missed TV recordings, incorrectly recorded measurements, incorrectly recorded transaction ledgers, erroneous data, deleted data, and overall impact to the economy (more than our politicians have already managed to do).
Paul (the CS guy, not my co-worker) has gone to sleep each night knowing the world’s computers are using his code to know what time zone they are in. He seems to be handling that pressure in strides and is at least owed a “thank you.”
Regarding my article last month about Winlink nets, some PAT client users have informed me standard Winlink forms are now fully supported. HTML forms support is fully implemented as of the July 2021 release. Those who built a system using KM4ACK’s Build-a-Pi programs will need to update and follow his video to make the necessary changes. New installs of Build-a-Pi will come with the latest configuration of PAT. Installs done through the procedure on the PAT website will have to manually update and make a modification to config.json. New installs should already have this value correctly set.
Thanks for reading and 73… de Jeff – K8JTK