Relativity

What if someone needed a software tool-thingy to help plan an itinerary, where people can create any number of events, set the time/date and duration for each, and if one event’s time were to change, all the other events that follow would update themselves automatically?

 

When trying to design the internal guts to help do this, it became obvious pretty quick that asking the software to “remember” the exact time/date and duration of every event would be as painful for me as Dawn of Justice was for others. Especially when events can be added/removed in any order, some events can last more than 24 hours, or the writer who did The Dark Knight kinda drops the ball.

 

So imagine mountains of crumpled paper, and a couple nights silently weeping in the corner of the office – all focused on how to keep track of a bunch of things that are dependent on one another.¹ What if we modeled an itinerary as a circle, and convert each event-time into an angle? Maybe we can manage all the events by adding/subtracting degrees, adjusting the radius of the circle if needed, and then rub some trigonometry on it to convert everything back into time when we want to display something.

 

spherical-time
A QUICKLY DISCARDED IDEA. SOMETHING ABOUT IT IMMEDIATELY FELT SILLY AND OVERLY COMPLEX. BUT CONVERTING TIME INTO SOMETHING ELSE IN ORDER TO BETTER MANAGE IT – THAT WAS THE GOOD STUFF.

TL/DR: Ugh, don’t even bother.

 

It turns out that all these events get easier to manage when you only try to remember the exact time and date of the very first one. We then tell the software to remember all subsequent events as, “occurring a certain number of minutes after event #1”, which can be thought of as an “epoch”.

Epoch: an instant in time chosen as the origin of a particular era.
The itinerary’s epoch is event #1, which we track in absolute terms (date/time). Every other event is tracked in relative terms – an amount of time AFTER event #1 began.

 

What if a friend said, “Let’s go to the movies 5 days after Monday, 3/28/2016.” Besides being someone who overcomplicates everything, that friend chose Monday as an epoch. In most cases, we can get away with remembering that our movie event is “5 days after” – we probably don’t need to remember the exact date, 4/2/2016.

linear-time
Tracking time relatively rather than absolutely.

So when our itinerary tool-thing needs to display a date or time, we tell it to take the very first event, add the appropriate number of minutes² to that and then convert into a typical date and time for display.

 

Q:  But how do you tell software to add “a certain number of minutes” to something like, 3/28/2016 @ 12:00pm?

A:  The internal guts of our tool-thingy actually keeps track of the very first event in minutes² as well, using another more commonly used epoch. The very first event in every itinerary is actually remembered as, “occurring a certain number of minutes” after Jan 1st, 1970.

 

 ¹ Obviously, the first event has no dependency on any other one.
² Yes nerds, the time references are in milliseconds, not minutes. Tomato, toe-mah-toe