Photo by Alexander Popov on Unsplash

Coding Coda with Time Slots

Should you use 2 columns if 1 can do the job?

Christiaan Huizer
4 min readMay 9, 2022


Playing with time tables

My co-worker created one column for the departure time and one for the arrival. It looks like below. I call it a time table for humans because it reads easily. You see the name of the line, the departure time, the arrival and the delta.

A time table for humans

I would not have noticed this approach if I would not also — from time to time — work with time tables that follow a logic like below. All the slots are put in one column. These are typically traject specific time tables for trains or buses.

Time slots in one column

Is the one column approach as you see above the better way to proceed or doesn’t it matter at all? To provide some context, below the aller — retour logic in one column, a variation of the first mentioned table. Do you see what I see?

Basic learnings

The first thing you learn is that the total amount of columns remains the same because you need a column to indicate what the line is about, arrival or departure (aller — retour). It is less human friendly with only time slots and there are only a few calculations that require you to bring the slots together while an obvious ‘duration’ calculation is easier and goes faster with two columns as you see below. The code snippet is elegant and easy to understand.

The length of the working day or the traject (duration) is the sort of information you need almost every time and should be easy to calculate. The second most required piece of information is about the trips per day. This one goes fast as well with the two columns and keeps the code readable.

It is only in the context of a getting the breaks during a single day, you need a fairly complex calculation that asks for a list of all time slots per line per day and you have to merge the values living in the two columns (Départ & Arrivé), see below in yellow. However even in this case the two column approach does not harm, instead makes it easier.

part of the calculation required to get the breaks


I guess that by now you understand my point, the human friendly approach has direct advantages in most cases, besides the visual appeal, even while dealing with complex calculations requiring a merge of two columns. The one column approach is valid in specific cases, for example as a detailed overview of a line to see all stops per line with their respective time slots.

When I create overviews for passengers and drivers per line, I put the time slots in one column, while calculations related to weekly & monthly overviews are easier with two columns. Coda permits us to chose the configuration we need. I really appreciate that.

In a next blog I dive into how to calculate breaks.

I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter

My name is Christiaan and I support SMB with calculations (budgets and planning) and I prefer using Coda to get the job done.

Not to forget: the Coda Community provides great insights for free once you add a sample doc.

Christiaan on: Coding Coda with Time Slots



Christiaan Huizer

I write about Mainly on Coda AI and interesting HR planning challenges. You find blogs for beginners and experienced makers.