pragmatic local time systems

Properties of Time

There are a few things about time that we could state (naively):

1. Time exists as a continuum of infinite proportion, which in turn acts as a context for all that lies within it.
2. Time can have any number of measures of arbitrary (yet consistent) size which can be used to recursively divide the time continuum, creating subcontexts of the time-space.
3. A moment within these contexts is a quantified, single point that has a specific value.
4. Any object (persistent manifestation) exists between two or more moments within a context.

These give us a basic starting framework in how to think about time.

In this article we’ll explore how we can create a system of time measurement that helps us maximize pragmatic efficiency in certain types of computational applications. We’ll overcome the need for using universal time constants in a local context and we’ll identify the benefit of working within a relative time scale instead of an absolute one.

A System of Time Measurement

When we wish to know the relative relationship (distance) between two points in the context of time, we do not need to know the totality of the entire continuum. We only need to know the immediate distance between the two points in question.

But imagine our continuum is an ever progressing line. If we want to measure a set of points on it, we have no way of really doing that within the context of infinity. We have to create a system of measurement that allows us to make the infinite space relative (and quantify it).

So, instead of thinking universally (and infinitely) we create local, relativistic time systems. There are two main components needed for a system of measurement:

1. A Governor: A pseudo-constant with which we can use as a delimiter to divide our continuum space and with which all moments in the continuum are ultimately quantified by.
2. The Present: A property that is incremented every time we delimit our continuum space using the governor. It acts as a benchmark which all moments in the continuum are measured in reference to.

The Governor

In the case of the real, physical world, we have a pretty solid constant to use as a governor. The consistency of the speed of light, c or maybe the planck constant, ℏ make them ideal for this role. In fact it seems that the speed of light and our experience of time go hand in hand in some magical relationship. We can use light as a reliable and consistent governor for measuring things within our space-time universe. And in real life, we experience time as a factor of the speed of light.

But for everyday, human work (eg. in offices, home, school, etc.), this type of ultra precise universal constant is not as relevant as a pragmatic time measurement tool. Instead we logically chunk the minute scale of time into measures that help us perform pragmatically in our world. We use clocks.

So, the measure of a governor at our (human) scale is used to quantify the passing of time. We use things like Months, Days, Hours, Minutes, Seconds etc. Programmatically, the interval of governance can be arbitrarily set. In the example below, nothing is happening at every measure, but events can occur at every tick. We’ll talk more about events later in the article.

var governor = 1000; // 1000 milliseconds
setInterval(function() {}, governor);

In a closed system all related workers within a local context can agree on a measure, and use the same governor as a reference point to synchronize their understanding of how time is being divided.

But many things can act as a local governor for time events. Anything that ticks or has a cyclical/repetitive mechanism can be used as a governor of time. A clock, the sun, the moon, a drummer, a metronome, a setInterval function(!). In fact, the reality is that it doesn’t even need to repeat exactly in harmonic progression with the continuum it’s in if it’s the only governor in the system. As long as all workers within the system adhere to its beat, the governor enables pragmatic measurement of time. This is further illustrated when we talk about the present.

The Present

Every time we delimit the continuum space with our governor, we have a property that increments, and acts as a measure of state. We can call this measure of state the present.

The present is actually a fairly mystical thing. It’s ever changing. Ever incrementing. It is a single value. It is the value of all dissections of continuum space made by the governor since the beginning of time (er, at least since the existence of the governor).

But since we say the continuum is infinite, what does that actually mean in terms of universal time? Perhaps the point here is that it doesn’t matter, pragmatically speaking. But for relativistic time, the present is a measure of all increments performed by the governor from its arbitrary start point. For example, when we say the time is 4:15pm, that number representing the present moment is only in reference to the previous midnight, when the clock reset.

var governor = 1000;
var present = 0;

setInterval(function() {
  present = present + 1;
}, governor);

This is an important concept, because the present only acts as a benchmark to compare against. The value contained within the present acts as an event time and, because it is quantifiable, it is also observable and recordable. These qualities that exist as properties of a moment (quantifiability, observability and recordability) are what allow us to compare time distance from moment to moment. We’ll get to this when we talk about comparing event times.

A Local Governor is an Efficient Governor

Every time we want to know the time, we check a nearby clock. We don’t calculate the space-time distance since the big-bang to find an exact value in reference to that moment every time we need to know the time. We don’t care about that level of universal precision. People sharing an office will share a clock and use that clock as a reference to synchronize their own office related events with.

Similarly, local computational events that need to be synchronized shouldn’t need to reference the computer’s very specific clock every time they want to synchronize events or compare time-distances that are purely local in nature.

Instead, we can create a local governor which may be relatively synchronized with a global clock for the sake of convenience, but creates a new measure of incrementation that is more appropriate for the specific local application. For example, instead of using milliseconds, a local governor increment might be much larger. This local governor can be used to capture the present, compare time-distances and synchronize a system of events quite a bit more efficiently than if we default to the universal governor of time (eg. the system time).

Pragmatic Needs

We can see we have suddenly built up the foundation for a framework of time-based manipulation that is arbitrary in nature and can be efficiently used for some of the most common applications of time:

1. Capturing event times.
2. Comparing event times.
3. Scheduling event times.

All of these help us understand and manipulate relationships between events (ie. those associated with an object or set of objects). And having a system that supports these with a focus on efficiency is the main goal of this exploration.

01 Capturing Event Times

In order to place a point onto our continuum of time, we need to capture the value of the present. We call these captured presents event times, or moments. We can then use this captured value to compare it to future values of the present or other moments in order to measure time distance.

t1 = present; // 1
// ... time passes
t2 = present; // 3

This may seem obvious, but the important thing to note is that the present is not the absolute universal time, but rather the current incremented state caused by the governor, we’ve called the present.

02 Comparing Event Times

Because we are using a local incrementation to capture event times, we only need to compare standard integer increments. We don’t need to retrieve and calculate event times based on Dates. We have them captured as locally relevant values in increments that relate to the local governor’s measure. Because all events are logged within this system of measurement, they can be easily compared!

And so we can use basic equality operators to guage relationships between event times. This is useful for understanding order of events.

(t1 < t2);
(t1 > t2);
(t1 == t2);
// etc...

The age of an event is quite simply a comparison of an event time to the present moment. By finding the difference between an event time and the present we get the age value. Knowing the age of something is super helpful for pragmatic applications because they can allow for scheduling or thresholding.

var t_age = present - t;

03 Scheduling Event Times

And now, perhaps the ultimate need of most pragmatic processes. We want to be able to manipulate the future. In order to do this, we need to be able to schedule events and synchronize specified events within the local system.

This is easily acheived by first comparing the future event time to the present time, and then literally counting along with every tick of the present until the present matches the future event time. When the present matches our event time, the event happens.

var governor = 1000;
var present = 0;
var events = [];

setInterval(function() {
  present = present + 1;
  checkEvents();
}, governor);

function checkEvents() {
  for (var i = 0; i < events.length; i++) {
    if (events[i].scheduled_time == present) {
      events[i].run();
    }
  }
}

Of course, this is heavily simplified but the important thing to note is that the precision of event coordination is quantified, and there are alternative ways of observing this through the use of age. But basically, scheduled events only happen the moment we enter into a new present that matches the value the event is scheduled for. That is, as soon as the present is incremented, all events that are scheduled for that present time are executed.

Conclusion

It might not be totally apparent how this philosophy manifests in actual application development. In the future (hah!) I’ll try and write a post to explain how to use localized time governors to expose efficient event operations through a simple interface, but for now check out this node.js module that I’ve written which surfaces all these ideas in a neatly packaged library.

Resources