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

Minkowski Spacetime

Posted on May 21, 02009
Filed Under Development, Drake, Journal, Kepler, Latham | Leave a Comment

"The views of space and time which I wish to lay before you have sprung from the soil of experimental physics, and therein lies their strength. They are radical. Henceforth space by itself, and time by itself, are doomed to fade away into mere shadows, and only a kind of union of the two will preserve an independent reality."

Hermann Minkowski, 01809

Time and Space
In the previous post I surmised that current temporal standards offer poor support for historical data. I also know that modelling time at deep timescales is going to throw up some new problems. The thing is, once you start messing around with time outside of historical systems like calendars you run into another dirty little secret. Time and space are related. We've known this for over a hundred years but temporal specs are all geared towards events in the short now, so fiddly little problems like relativity are conveniently ignored.

Even if I ignored relativity, I can't ignore space. Recent temporal innovations like daylight saving time and the timezone system are all local modifiers based on spatial coordinates. What I find odd is that I haven't encountered a single specification that tries to treats time and space equally.

Hermann Minkowski
The German mathematician Hermann Minkowski (1869 - 1909) was the first to formalise the notion that space and time are not separate. He proposed that the best way to understand Einstein's special theory of relativity was to use a 4 dimensional space he called spacetime. It's often referred to as Minkowski spacetime to differentiate it from a slew of other modern multi-dimensional theories.

Getting your head around the ideas of relativity and spacetime isn't as hard as you might expect. I found some great articles here that walk you through all the concepts using simple examples. Getting my head around the mathematics of spacetime is another thing entirely!

Minkowski image via AIP Emilio Serge Visual Archives

Revelation

Posted on May 14, 02009
Filed Under Development, Drake, Herodotus, Journal, Kepler, Latham | Leave a Comment

Getting external data into Herodotus is an important part of the project. Data can be encoded in a wide array of formats and they all have to be parsed into Actionscript Value Objects. I've yet to define the metadata for these VOs so in an effort to find some commonality I spent much of the last few months digging through a mountain of  temporal specifications, projects and APIs. It's been hard work and a journey peppered with surprises and revelations. Over this and the next two posts I hope to cover some of what I've learned and how this has shaped my semantic model of time.

The semantics of time
The properties of time are elusive. It's a fundamental concept with a myriad of definitions, each dependent upon the experiences and requirements of the individual or group who defines it. Disciplines as diverse as physics, chemistry, biology, astronomy, theology, philosophy, history, music and politics have all had a hand in shaping our definitions of time.

It's fascinating to watch different people approach the same problem. Some attempts make you want to scream "oi, no!", and others have you immediately reaching for your notebooks; throwing out old ideas in favour of new, each revelation informing your overall understanding of the problem.

The fundamentals and architecture of time require some deep thought and on the whole this is evident in the specifications I looked at. The introduction to the ISO8601 specification gives a good introduction to the basic temporal concepts of a Timeline, an Instant and an Interval. The Time ontology in OWL describes them in a little more detail. These three concepts seem to be universally applied or at least implied in all of the specs I looked at.

Old Father Time: ISO8601
In a review of Temporal Web Standards I showed that almost all web standards for DateTime have their roots in the ISO8601 specification. This was great because it gives me the commonality I was looking for.

Unfortunately this common ancestry throws up another problem, but before I get into that it's worth noting the main innovations to take from ISO8601:

• Dates are human readable.
• Dates are stored internally in UTC and converted to local time as required.

When date and time are represented as strings they are formatted in order of granularity, from largest to smallest. This offers the following advantages:

• Dates are language neutral.
• Dates are unambiguous.
• Dates are machine sortable.

Julian 1.1
Now for the bad news. ISO8601 models our modern civil "Gregorian" calendar. Introduced in the Inter gravissimas papal bull by Pope Gregory XIII this system of measuring time reformed the earlier Julian calendar. The difference between the two calendars is small - only a slight change to the leap year rule to correct the drifting date of Easter. In software terms the Gregorian calendar would be considered a patch: it's Julian 1.1.

The problem of dating historical events with ISO8601 is really one of practicality. The reform came into effect, in Catholic countries at least, in 1582. The thing is (rather obviously) a lot of history happened before then. These sorts of dating problems aren't new to historians but the conversion to Gregorian, and often back again, can be non trivial.

For example, meet Tom. Tom is a historian studying the French Revolution. He has found a date on a document that uses the short-lived put completely wonderful French Republican calendar. The FRC was a metric calendar (10 days in a week, 10 hours in a day etc.) adopted very briefly alongside the rest of the metric system. If Tom wanted to store information on the web about this document he would have to convert the date from French Republican to Gregorian.

The Proleptic Gregorian Calendar
The common response of spec writers to the problem of historical dating is to use the proleptic Gregorian calendar. A proleptic calendar is one in which the calendar rules are extended backwards in time before when the calendar was introduced. Now this sounds like a great idea until you actually try and use it.

Meet Tom again. This time he is studying the life of Julius Caesar. Caesar was born when one of many permutations of the Roman calendar was in effect, and he died two years into the counting of his eponymous Julian calendar. Dates in his life require conversion from at least two different calendar systems into the proleptic Gregorian. Just to add to the complexity all of those dates are considered BC in the Julian/Gregorian calendars. While most implementations of proleptic Gregorian (including ECMAScript) happily count zero and on into negative numbers, the proper BC/AD (or BCE/CE if you prefer) system doesn't count a year zero. 1AD is preceded by 1BC. Conversions like this are complex and error-prone. I really don't think the proleptic Gregorian is a very practical storage solution.

As if I haven't rammed the point home enough then consider a further example. Meet Dick, he's a geologist studying the Cretaceous Tertiary boundary. What is 65.5 million years ago in Gregorian? It's all a bit fuzzy. Don't even bother asking Harry the cosmologist.

The revelation
Once you realise there is no practical support for historical events prior to 1582 it quickly becomes obvious why we don't yet have a deep-zoom for history. No online support = no online data. To pull this off I need a model of time (and space, but I'll get into that later) that goes back beyond the common Gregorian calendar and in fact beyond any calendar into the timescales of geology and cosmology.

Project updates April 2009

Posted on April 29, 02009
Filed Under Bede, Development, Drake, Flash, Herodotus, Inspiration, Journal, Kepler, Latham | Leave a Comment

Open Knowledge Conference 2009
A few weekends ago I gave a short talk about The Computus Engine at the Open Knowledge Conference in London. It was interesting to attend a con outside of the usual Flash circuit, and with Open Knowledge being so 'em... open, it meant there was a wide range of topics under discussion. I missed the first part of the day but in the afternoon we were treated to everything from open source fashion (image below), to aid work in Africa, to the intricacies of semantic markup.

The open philosophy is applied to the con as well as the subject matter. Much like BarCamp, speaking slots can be added to the schedule by audience members. Fitting everything in meant I rattled through mine at breakneck pace but I think I got my points across. I've submitted the slides to Jonathan Gray at The Open Knowledge Foundation and I'm told they have audio as well. If they put them up online I'll post a link.

New class documentation
I finally got round to configuring ASDoc (the Actionscript class documentation generator) in FlexBuilder. It's notoriously painful to configure but thanks to my friend Seb for publishing his efforts it gave me enough clues to get mine up and running. Since then I've worked my way through the current set of classes and marked them all up. Taking another tip from the PV3D team I'm checking the docs into the repo alongside the code so they'll always be in sync with the codebase.

GoogleCode repo updates
Yesterday I checked in a stack of updates to the Computus Engine repo on GoogleCode. In addition to the ASDoc markup and docs directory you'll also find updated examples for the Animated Main Preloader and the Timekeeper. The preloader now has a fix to resolve the problem of it stalling if the SWF is already cached.

More importantly I've made a change to the Timekeeper API. I've replaced a number of methods with single properties to reduce the complexity of the API. The affected methods are:

value:Number replaces getValue() and setValue()

tickDuration:Number replaces getTickDuration() and setTickDuration()

tickFrequency:int replaces getTickFrequency() and setTickFrequency()

I don't like changing a live API but I think these changes are sensible and greatly simplify things. The Timekeeper test example has been updated to use the new API.

A  S.T.A.R. is born
Eagle eyed visitors will also spot a new set of unit tests and util directory called star. More about this in a forthcoming post!

Hacking the Date class for GeoLocation

Posted on April 23, 02009
Filed Under DaVinci, Development, Drake, Flash, Journal, Projects, Timelines | 1 Comment

The demo above attempts to locate your current position on the earth. I can't take any credit for the 3D stuff as I based it on Andy Zupko's great post about Geolocation in Papervision3D. My little contribution is the code below. This takes the humble Date class and does some reverse engineering on it to derive your approximate location on the earth. First the code, then I'll explain how it works...

// Estimate Latitide and Longitude from the Date class.
var latitude:Number
var longitude:Number
var now:Date = new Date()
var northernWinter:Date = new Date( 2000, 0, 1 )
var northernSummer:Date = new Date( 2000, 6, 1 )
var northernWinterOffset:Number = northernWinter.timezoneOffset
var northernSummerOffset:Number = northernSummer.timezoneOffset

// Find just the Timezone modifier TZD (in minutes).
// DST modifier is negative so TZD is the larger value.
var tzd:Number = Math.max( northernWinterOffset, northernSummerOffset )

// if you need the current value of DST (in minutes) it's...
var dst:Number = now.timezoneOffset - tzd

// Estimate Longitude:
// 60 minutes of time == 15 degrees of longitude.
longitude = tzd / -4

// Estimate Latitude:
// If DST is adopted we can detect the current season and from that we can find the hemisphere. If not assume equatorial.
if ( northernWinterOffset == northernSummerOffset )
{
  // equatorial
  latitude = 0
}
else if ( northernWinterOffset > northernSummerOffset )
{
  // northern hemisphere
  latitude = 45
}
else
{
  // southern hemisphere
  latitude = -45
}

// and the estimates are...
trace( "Longitude: " + longitude )
trace( "Latitude: " + latitude )

Last year I wrote a series of posts that looked Inside the AS3 Date class. One of the gotchas I mentioned was the confusingly named .timezoneOffset property which is actually comprised of two offsets: timezone designation (TZD) and Daylight Saving Time (DST). In the article I showed some code that split these values back out again. Well it struck me the other day that you can use these values to approximate a users position on the earth. The cool thing about this hack is that it relies solely on understanding the mechanics of timezones and daylight saving, so itl will work just as well in Javascript as it does in AS2 or AS3.

If you follow the code above you'll see the first thing we do is split out TZD and DST. Once you have these values you can make some estimates about latitude and longitude.

TZD ≈ Longitude
The earth rotates once on it's axis each day so that's 360° in 24 hours, or 15° of longitude every hour. So if we know a user's TZD we can estimate their longitude (east/west) to within about 15°. In reality timezone boundaries are a little wobbly so I'd gave or take another 15°.

DST ≈ Latitude
Using DST to estimate latitude is really inaccurate but if you need to know then this way is better than nothing - here's the theory anyway. As a general rule Daylight Saving Time is adopted by countries with temperate climates. Employing it nearer the poles is pointless and the last thing you need at the equator is more sunshine. In the code above we created a summer and a winter date. By comparing these we can tell if the user's current location employs DST and if it is currently in effect.

There are plenty of special cases for DST (don't get me started on that) but if no DST offset exists in summer or winter then the user is probably within the equatorial band. If DST exists but is not in effect then that hemisphere is in winter, and the opposite hemisphere is in summer. A quick check against the current date will tell you which hemisphere that temporal band is in.

Caveat Emptor
So there you go, GeoLocation using just the Date class. I'm the first to admit that determining latitude is really inaccurate so if you need to know for sure then use server side IP Location. If accuracy is less important then this method is small, self contained and works in AS3, AS2 and Javascript. One last piece of trivia before I finish up; although I said employing Daylight Saving Time near the poles is largely pointless, it turns out that for reasons of synchronicity most Antarctic survey stations follow the DST rules for their home country.

The Prime Meridian

Posted on April 16, 02009
Filed Under Drake, Journal | Leave a Comment

Toeing the line
If you visit the Royal Greenwich Observatory you'll often see groups of tourists jostle for position to have their photograph taken "on the prime meridian". The notion that you can stand with one foot in the western hemisphere and one foot in the eastern hemisphere is pretty cool. What seems to elude many of them however is that the prime meridian isn't a place, it's a line. It's a line of longitude runing north/south from pole to pole. If you were so inclined, there's a petrol station on Greenwich High Road where you fill up your car with one foot in the western hemisphere and one foot... well, you get the idea.

The other thing to remember about meridians is that they are the astronomical equivalent of an "imaginary friend". We talk about them as if they are real, but they are only consensual human constructs that mark nothing more than where an astronomer placed his telescope. The prime meridian is in reality the Airy meridian - marking the position where the astronomer royal George Airy made his observations.

View Larger Map

This becomes more obvious with a visit to the RGO where you'll also find a Bradley meridian, a Flamsteed meridian and a Halley meridian, each within a few yards of each other; and each marking the position where the eponymous astronomer (that's hard to say) fixed their observing apparatus. Just to confuse matters further if you take a GPS receiver with you, you'll discover the GPS meridian is somewhere else again. It doesn't even run through the observatory; but several yards east near the statue of General Woolfe.

125 years of the Prime Meridian
In October this year the RGO are commemorating the 125th anniversary of the selection of Greenwich as the prime meridian of the world. I've mentioned the 1884 International Meridian Conference here before but if you are interested in the full story behind the prime meridian I'd recommend getting hold of a ticket for Graham Dolan's lecture, The Greenwich Meridian and its significance to the World.

Graham is an entertaining and humorous speaker and an expert on the meridian. A few years ago I attended a seminar day at the RGO entitled 'On the line' - not to be confused with the RGO podcast of the same name. Graham showed a high-speed photo slideshow of markers and monuments along the prime meridian. I've always thought this collection would make for a great Google Maps mashup!

keep looking »