Archived Posts from this Category

Earth, Moon, and abolishing leap seconds: the curious astronomy and politics of time() (IUC44 session)

Posted by on 30 Nov 2020 | Tagged as: culture, meetings and conferences, time, Unicode

Last month was the pandemic-distanced rendition of the Internationalization and Unicode Conference. This year is the 44th conference, or IUC44.  In addition to a tutorial (blogged about last month), I delivered a presentation: Earth, Moon, and abolishing leap seconds: the curious astronomy and politics of time(). Here are my slides, and a video of me talking through my slides.

Continue Reading »

Happy new decade, yes, 2020 not 2021

Posted by on 31 Jan 2020 | Tagged as: culture, robobait, time

Happy new decade, everyone! This month, January 2020, marks the start of a new decade, the 2020’s. And for those of you who are saying, “no, strictly speaking the decade doesn’t begin until 2021”, you are wrong. Or, at least, all of us who say that decades and centuries start on round numbers are just as “strictly speaking” right as you. Here is why.

I think we all agree that a “decade” generally means a 10-year time span, and a “century” means a 100-year time span. In everyday usage, the word “decade” means a time interval which starts on a year ending in “0”, and ends on a year ending in “9”. Thus we have just finished the “2010’s” (10 years from the start of 2010 to the end of 2019), and are entering the “2020’s” (2020–2029). By the same token, every-day use of the time unit “century” means a time interval which starts on a year ending in “00” and ends on a year ending in “99”. The previous century is known as the “1900’s”, and also as the “20th century”.

And all of the above only applies to English usage of North America, when using the current standard Gregorian Calendar. It is also limited to year 1 onwards — the Common Era (earlier labelled as Anno Domini or A.D. by Bede back in the 600’s and 700’s).
The pedants will point to the first year of the Common Era, which is year 1 rather than year 0. They argue that the first decade must begin with year 1 and be 10 years long, so it must end on year 10. Count forward in 10-year increments, and the 2020’s must start with the year 2021 and end with the year 2030. Similarly, the pedants argue that the first century must begin with year 1 and be 100 years long, so it must end on year 100. Note that the entire foundation of their pedantry is that the time unit “decade” must always and only be 10 years long, and “century” must always and only be 100 years long.

I believe that where the pedants go astray is to prize a constant length over a convenient starting point for “decade” and “century”.

Decades, and calendars, are social constructs. They don’t have to abide by strict mathematics, and they don’t. There is a value to having a calendar which matches the earth’s rotation around the sun. There is value to having a calendar which adjusts to seasonal changes in sunrise and sunset. And, there is value to having a calendar which matches common and convenient language usage.

Consider the day: normally it is 24 hours long. But when “springing forward” from Standard to Daylight Saving Time, there is a day which is 23 hours long. Later in the year, when “falling back” to Standard Time, there is a day which is 25 hours long. I have had to write software which handled this variation. A day is normally 24 hours, but can be 23 or 25 hours.

Consider the minute: normally it is 60 seconds long. But when a leap second is necessary — to keep the highly-accurate Coordinated Universal Time (UTC) in sync with the Earth’s variable orbital duration, and to keep the March equinox close to March 20 — the minute containing the leap second is 61 seconds long.

Some years are 365 days long, others are 366 days long, because of leap years.

Britain officially started its civil year on 25 March, until as late as 1751. Only in 1752 did it finally change the start of the civil year to 1 January. Common usage was ahead of civil rules in adopting 1 January as the beginning of the year, leading dates from 1 January to 24 March to be written with two alternative years: “30 January 1648/1649”.  Even more interestingly, September 1752 was 19 days long in England, instead of 30 days as in other years. This was to bring the calendar back in sync with the solar year, or in other words, to move March 20 back to the day of the March equinox.

All these calendar shenanigans are about deciding to allow social (and astronomical) considerations take precedence over strictly consistent numerical duration. “Strictly speaking”, a calendar balances all these considerations. And rightly so.

Given that, I think it is perfectly reasonable to declare: decades are normally 10 years long, but the first decade of the Common Era was 9 years long: 1 to 9 CE. 10 CE began the second decade. Centuries are normally 100 years long, but the first century CD was 99 years long: 1 to 99 CE.

Thus, 1 Jan 2020 CE also began a decade. Pedants, I see where you are coming from, but if you are willing to use a calendar with 25-hour days, and a 19-day September back in the day, I claim you cannot justify denying the 9-year decade and the 99-year century.

I am tempted to find a time machine, go back to northeast England in the 7th or 8th centuries CE, and persuade Bede to define his Anno Domini year numbers at 0, instead of 1. It would sidestep this whole decade and century problem. The only problem is, that in Bede’s time, Europe would not learn of the zero for another 3-5 centuries (where “centuries” are not strict 100-year time durations).

Happy new decade, starting January 2020!

Adventures with the Solar Hijri calendar

Posted by on 31 Jan 2019 | Tagged as: culture, i18n, multilingual, time

 Recently, an innocent attempt to correct an error, in a birth date cited in a Wikipedia article, led me to a lesson in the Solar Hijri calendar, used in Iran. It was another wonderful reminder about how interesting and subtle are the calendars and clocks across cultures. Cultures can can approach the task of keeping track of days and years so differently, despite all of us living on the same planet, orbiting the same star and watching the same moon. Continue Reading »

Heads up for 1234567890 day!

Posted by on 12 Feb 2009 | Tagged as: software engineering, time, Vancouver

1000000000 seconds since the POSIX epoch, as celebrated in Denmark in 2001During a high school class, my teacher interrupted his discussion of classical Greek history to say, “it’s twelve thirty-four on the fifth of June, 1978”. In other words, 12:34 5/6/78 (in the British notation). Alert people in the United States had already celebrated that moment on May 6th. If you missed that moment, you have another chance on Friday: 1234567890 day.

Humans love to find patterns, and dates have rich potential for that. For instance, I was walking through a train station on a business trip in Tokyo in February, 1990. I noticed that people were making an unusual fuss about the train tickets. 1990 was 平成2年 , or “Heisei year 2”, in the calendar based on the Japanese era name. The date was printed on the train tickets as “H2-2-2”. The symmetry made them collectors items. (I wish I could lay my hands on a ticket from that day, to convince myself I didn’t invent this memory…)

I have a fondness for finding leaks in the software engineering abstractions that represent our messy real world.  I wrote last year about POSIX time, and the limitations in its representation of modern calendars and time zones. So when a leaky abstractions turns up as a pretty pattern, it’s irresistible.  And that’s what happens this Friday.

Continue Reading »

Times Change, or, We Live In Complex Times

Posted by on 24 Mar 2008 | Tagged as: history, software engineering, time

A few days ago, I had to set the clock on my GPS unit. My GPS unit! It talks to over 24 satellites, each of which has atomic clocks accurate to nanoseconds — yet it didn’t know that Daylight Savings Time began in March instead of April.

We software engineers use variety of abstractions to represent points and durations in time. We synchronise to time servers which are accurate to the millisecond. Behind them are atomic clocks. Our abstractions can represent times centuries in the past and future. They are tidy, regular abstractions. But Daylight Savings Time is a reminder that the reality of time is messy and irregular. It is affected in small ways by astronomy, and in large ways by politics and human idiosyncrasy. That’s why I had to manually set the clock on my GPS unit.

One of the thing I love about engineering is where technology meets human idiosyncrasy. The technology bends to support the idiosyncrasy, and the human idiosyncrasy bends to fit the technology. Time representation is one such case.

Many software systems have an abstraction that represents time in terms of the number of seconds since some special reference date and time. <time.h> is the POSIX manifestation of this, storing times as integer numbers of seconds and microseconds since a 1970 reference time. From the integers, the system computes human-friendly structures like years, months, dates, hours, and minutes (leap years are no big deal). There’s a mechanism for converting from Coordinated Universal Time (UTC) to local time in various time zones. This includes Daylight Savings Time. All very tidy.

But when you start to look hard at time zones, things start to get interesting. Most of us live in time zones which are whole numbers of hours before or after UTC. In Vancouver, Canada, local time is eight hours earlier than UTC during Pacific Standard Time, and seven hours earlier than UTC during Pacific Daylight Time. But the time in Newfoundland and Labrador, on Canada’s east coast, is 30 minutes rather than an hour offset from its neighbour to the west. Afghanistan, India, Iran, three zones in Australia, and Venezuela also have time zones 30 minutes out of phase with most of the world. Nepal and Chatham Island, New Zealand, are 45 minutes out of phase: when it’s 05:00h in Vancouver, it’s 01:45h on Chatham Island. Time zones were regularised greatly in the 19th and 20th centuries. Before then, some timezones were arbitrary minutes and seconds out of sync with each other. (The TZ data set, tzdata2008b.tar.gz or its successor, is a fascinating read, with lots of historical time zone information and bibilographies.)

Daylight Saving Time has a richer and more controversial history than you may have known. David Prerau’s book Seize the Daylight: The Curious and Contentious Story of Daylight Saving Time“, gives three centuries of that history. It’s reasonably well known in North America that some jurisdictions observe daylight saving time and some don’t. What’s less appreciated is that the rules for daylight savings time vary over time. Many software systems, even when they provide for time zones and daylight savings time, do so through static data tables. They get caught out when, as in the Energy Policy Act of 2005 in the USA, or every year in Israel, somebody decides to change daylight saving rules. Most software systems don’t have a way of describing all the historical changes in daylight saving time; they do really well to store one historical rule for a time zone. This is what happened to my GPS unit. I’ll have to manually set its daylight saving time until the maker comes up with a firmware patch that corrects the time zone tables.

About those time zone labels, like “CST”: they are ambigous! “CST” can mean “U.S./Canada Central Standard Time, Australian Central Standard Time, China Standard Time, or Cuba Summer Time“, points out Raymond Chen in “The Old New Thing“. Software systems generall don’t well with the ambiguity. Specifications for representing dates in plain text, such as the W3C’s profile of ISO 8601, “Date and Time Formats” or RFC 2822 – Internet Message Format, section 3.3. Date and Time Specification, are important because they offer a way to write dates unambiguously.

Another problem that crops up when time zone definitions vary, be it for daylight saving or other changes, is that it becomes more complicated to calculate time spans. If I want to calculate the number of seconds between April 1, 2005 08:00h and April 1, 2008 Vancouver local time, I’ll need to allow for the fact that the 2005 time is standard time but the 2008 time is daylight savings.

I’ll also need to allow for leap seconds. Remember that abstraction that each day has 24 hours, each hour has 60 minutes, and each minute has 60 seconds? Well, usually that’s true. But some minutes in UTC are defined to be 61 seconds long, so some days are 86,401 (instead of 86,400) seconds long. These leap seconds get added by the International Earth Rotation and Reference Systems Service (IERS) in order to keep the sun rising on time. It turns out the earth actually takes a bit longer than 24 hours * 60 minutes * 60 seconds to turn one day, so without leap seconds the sun would rise later and later UTC. ( You’ll be glad to know there will be no leap second on June 30, 2008. Way to turn, planet Earth!)

So to calculate that time span between 2005 and 2008 correctly, I’ll need to allow for the minute of December 31, 2005 23:59h UTC being 61 seconds long.

So seconds are small and finicky. Surely we can be confident about the date, right? Well, that’s complicated too.

Trivia question: on what date in 1917 did Russia’s “October Revolution” occur? Well, on November 7, of course! It was October 25 in the Julian calendar in use in Russia at the time (“old style”), but November 7 in the current Gregorian calendar (“new style”). They differ by 13 days this century. These calendar differences are widespread across the world over the last 1000 years. Until 1750, England’s civil year started on March 25, not January 1. Thus January 30 1649 (“new style”) was known at the time as January 30 1648 (“old style”). Wikipedia can tell you way more about these “Old Style” and “New Style” date complexities.

On many world maps, there is an “international date line” zig-zagging across the Pacific ocean. To the east of this line, local time is earlier than UTC; to the west, later than UTC. I hate to be the one to break it to you, but this line doesn’t actually exist. Time zones are the choice, essentially political, of human jurisdictions. That zig-zag on the map is the cartographer’s way of showing you which time zones are which side of UTC.

Being political, time zones can change dates. The Pacific island republic of Kiribati stretches from 172° E to 150° W longitude. Centered in the Gilbert Islands in a time zone 12 hours after UTC, upon independence it acquired islands to the east in time zones 11 and 10 hours before UTC. This meant that the ends of the country observed different dates, and only four days per work week overlapped. Effective January 1, 1995, Kiribati changed the Phoenix Island and Line Island time zones to 13 and 14 hours after UTC respectively. This changed their dates, so finally, the whole country was on the same date. But beware if you have to compute a time span between 1994 and 1995 for Kiribati, because their local time didn’t include December 31, 1994! Nevertheless, they didn’t (pace Wikipedia’s Geography of Kiribati article) move the International Date Line, just some time zones.

Usually the <time.h> abstraction of time, as a count of seconds and microseconds after a certain reference date and time, works plenty well for software engineering. There are certainly many sources of error in our time data (inaccurate clocks, clobbered time stamps) that are much greater than the limitations of this abstraction. But remember, time measurement is a human convention, and human conventions almost always have really interesting complexity, and variation over time.

Don’t let the tidiness of the abstraction blind you to the richness of the reality.