• Home
• About
• Articles
• Contact
• Downloads
• Glossary
• Links
• Projects

Measuring Time: Periodization

Posted on July 29, 02008
Filed Under Herodotus, Journal | Leave a Comment

The categorisation of timespans is called Periodization. It's a process practiced by scholarly groups as diverse as cosmologists, geologists and historians. In an effort to unify all of these periods into an accurate and integrated timescale I have chosen five broad bands of time that I want to be able to work with: These are Quantum, Civil, Historical, Geological and Cosmological. Each band deals with periodization at a different granularity and overall they form a logarithmic scale that encompasses all of time.

Cosmological Time
This is everything from the Big Bang through the formation of galaxies and the solar system and onwards to the theoretical death throws of the universe. Every cosmological period will cover a vast span of time. The standard period granularity for cosmological time is bya (billion years ago).

Geological Time
This band covers the various geological eras, eons and periods that span the geological formation of the earth. The standard period granularity for geological time is mya (million years ago).

Historical Time
This is the band that covers the extent of human existence. It is also the band with the most diversity of measurement systems. Not only are there hundreds of religious calendar systems, there is also a multitude of other ways of counting such as regnal, legal and pontifical dating to deal with. This is going to be huge. The standard period granularity for historical time is the year.

Civil Time
This band covers the seconds, minutes and hours of our daily cycle. The standard period granularity for civil time is the second.

Quantum Time
This band covers the very small timespans below one second. I haven't really dug into this yet but the standard period granularity for quantum time is likely to be either the Chronon or Planck time.

Measuring Time: A simple linear timescale

Posted on July 22, 02008
Filed Under Journal, Latham | Leave a Comment

In the previous post I decided against using Date as the fundamental temporal datatype for The Computus Engine. Instead I'll be using the datatype at the heart of the Date class; and that is Number. Backwards compatibility with Date is still important so I'm going to use the same epoch (all dates are measured from 1st Jan 1970) and the same granularity (1 unit = 1 millisecond). I will in effect be using the same underlying timeline that the Date class uses, just without any of the calendar specific overhead.

The importance of a linear timescale
If you take all the possible values of this system and graph them you would get a very simple linear timescale. This is a good thing. The rules for most calendar systems are complex and arcane so a timescale that is simple, regular and predictable is very helpful. I don't mean helpful for "telling the time"; more as an underlying and intermediary system for calendar conversion.

Time is money
An intermediary timescale works a bit like money. Disperate commodities and services all have a monetary value (even if they are free) and this common intermediary scale allows for the simple interchange of just about anything. What's interesting is that on it's own money is useless but used as an exchange mechanism it's invaluable - if you'll excuse the pun.

[kml_flashembed movie="http://www.computus.org/downloads/Measuring_Time/LinearTimescale.swf" height="300" width="470" /]

A simple intermediary timescale provides every calendar system with a common reference for exchanging temporal data. Instead of writing dozens of routines to convert every system to every other system, you just write a couple of routines for each system to convert them to and from the intermediary timescale.

Julian Day Number
If you look at other systems of calendar conversion you'll usually find an intermediary scale being used, the most common being the Julian Day Number (JDN). This and the Modified Julian Day are both popular with astronomers. JDN should not to be confused with the Julian calendar (from which our modern Gregorian calendar is descended) as the Julian Day Number is a linear count of the number of days since January 1, 4713 BC. The reason behind that date is of course another story.

Measuring Time: Datatypes

Posted on July 17, 02008
Filed Under Development, Flash, Latham | 2 Comments

In order to build a timeline that can display any point in time I'm first going to need a datatype that can represent any point in time. It needs to be able to cope with any event from the Big Bang to a potential Big Crunch - that's roughly 13.7 billion years either way. In this post I'm going to look at the two likely candidates for this temporal datatype: Date and Number.

Date()
The standard way of storing a point in time in Actionscript is to use a Date object. The purpose of this class is to simplify the process of working with the various cycles of the modern Gregorian calendar. What's interesting about Date however is that for all its many methods and properties, it's internal value is stored as a single number representing the total number of milliseconds that have elapsed since the 1st of January 1970. This somehwhat arbitrary reference point or origin is known as the epoch. When a programmer calls a method of the Date class, this base number is converted back into a human friendly value before being returned.

The Date class does a great job when working with contemporary dates and times but I need to store values far beyond this period. A few simple tests show that the Date class fails with historical dates prior to the late 1500's. This is because the Date class is a representation of the Gregorian calendar and that system of quantifying time did not come into effect until 1582a.d.

I need a datatype that is calendar system agnostic. This will allow me to take a value and render it with reference to any calendar system, historical event or astronomical cycle.

Number()
The obvious choice then is Number. It is after all at the root of the Date object as well. If I use this datatype but maintain the same epoch as the Date class then I can very easily transition between both systems. I haven't done any speed tests on this but I strongly suspect doing calculations with Numbers will be faster than with Dates.

As an aside AS3 offers us a couple of alternatives to Number in the shape of int and uint. Whilst these are useful in other situations a quick capacity test reveals they aren't large enough to hold the values I need. Number however is quite comfortable with values as far back as the beginning of the universe itself.

2008 just got one second longer

Posted on July 14, 02008
Filed Under Journal, Latham | 1 Comment

You'll have to be pretty quick to celebrate it but just before midnight on the 31st of December 2008 a leap second will be added to UTC. I've mentioned leap seconds before but as my good friend Tom Coxen helpfully pointed out, I didn't bother to explain them. Hopefully I can correct that here.

Most people know two things about UTC: that it's a global time standard and that it's the modern equivalent of GMT. They might also feel safe in the assumption that it is extremely accurate because it is regulated by modern atomic clocks. This is all true but probably the most important characteristic of UTC is that it is a man-made timescale - a rigid framework of periodic intervals designed to provide uniformity. It is this rigidity that can sometimes be a problem.

UTC and UT1
The story of how we arrived at UTC is a fascinating and colourful one but one I'm going to have to put to one side for today. Suffice to say UTC is not alone. It is linked to another timescale called TAI-UT1.  This is the timescale that measures the actual rotation of the earth. The problem with synchronising a rigid timescale like UTC to a dynamic one like UT1 is that the earth suffers from the same problem as the AS3 Timer class - it's not very accurate.

The concept of leap days are familiar to most of us. Every four years (on the whole) an extra day is inserted into the end of February. These intercalary days, as they are known, keep the modern Gregorian calendar in sync with the orbit of the earth around the sun. The same principle is applied to the movement of the earth and UTC. The two are kept in sync by the addition or removal of leap seconds from UTC.

The organisation in charge of monitoring such things is the snappily named International Earth Rotation and Reference Systems Service, or IERS for short. A week or so ago they issued Bulletin C 36, an advisory notice about the insertion of a leap second into the end of December 2008. What's interesting about this leap second is that it comes at the end of a leap year, making 2008 (along with 1972, 1976 and 1992) an extra long year.

ECMAScript and Leap Seconds
If you are an Actionscript or Javascript programmer and you're encountering leap seconds for the first time you might be wondering to yourself, is there anything I should do? Put a paper bag over my head or something? Well don't panic. Actionscript is based on ECMAScript and the ECMA 262 implementation of UTC gets round the thorny problem of leap seconds by completely ignoring them.

Dendrotech and hand made computers

Posted on July 8, 02008
Filed Under Inspiration, Journal | 1 Comment

The first television set I remember was a black and white affair that came encased in a large wooden box. Looking back on it a lot of early consumer electronics came in those wooden boxes; some beautiful, some not so, but after years of plastic domination, wood is making a comeback. Tree-V from Sweden offer a range of wooden framed televisions and Miniot from Holland manufacture some beautiful wooden cases for your iPod.

I'm a great admirer of case-mods like the Steampunk laptop and large scale hand made computers like the The Clock of the Long Now and Babbage 's Difference Engine. The Computus Engine is not a physical object but it is hand made, and I'd very much like the interface to exhibit some of the charm of traditional hand-crafted materials.

keep looking »