The trip day: why day three is not a date until a departure is chosen
In short
In a trip data model a day is an integer offset from departure, not a calendar date: day 3 becomes 14 March only when a departure is chosen, and the date is derived on demand. That single decision is what makes the 2 everyday operations survivable — moving a departure without re-dating every service by hand, and inserting a day without silently breaking the hotel stay that spans it.
Key takeaways
- Store the offset, derive the date: date of day n is departure plus n minus 1, in the trip's calendar.
- Add calendar days in a named timezone, never 86,400 seconds, or a clock change shifts every service by an hour.
- Inserting a day into a multi-night stay forces a choice between extending and splitting. The system must ask, not guess.
- An overnight service occupies 2 day slots and is still 1 component — duplicating it is what doubles the operations sheet.
- Derived dates may be cached only on rendered documents, stamped with the revision they were rendered from.
A trip day is an integer. Day 1 is the departure day, and the calendar date of day n is departure plus n minus 1, computed when somebody needs to see it. Before a departure exists there is no date to store, which is why a template can exist at all: a 12-day itinerary is 12 offsets and a set of services, sellable in March and October with nothing edited.
Days hold services and are not services themselves. What sits inside them is the object defined in the itinerary component; the day is the container giving each one its position.
What a day actually carries
- An offset. The integer position in the trip, and the only date-like thing stored.
- A location or leg. Where the traveller wakes up, which is what an operations sheet and a routing check need.
- Presentation content. A title and description belonging to the day rather than to any component on it.
- Nothing resembling a date. Once a day record holds its own calendar date the model has 2 sources of truth, and one stops updating.
The two operations this model exists for
Shifting a departure proves the model. With offsets stored, changing the departure changes 1 field: every service date, transfer leg and voucher date follows on the next read. With calendar dates on each component, a departure moved by 2 days is a bulk update that will miss something, and what it misses is usually a supplier request already sent.
Inserting a day is the hard one, because it is the operation that exposes services spanning more than 1 day.
| Element | Before | After | Decision forced |
|---|---|---|---|
| Hotel A, 3 nights | Check-in day 3 | Check-in day 3 | Extend to 4 nights or split — the system must ask |
| Guide, full day | Day 4 | Day 5 | Automatic |
| Domestic flight | Day 6 | Day 7 | Automatic; the supplier request must be re-sent |
| Airport transfer | Day 8 | Day 9 | Automatic |
| Balance due date | Departure minus 45 days | Departure minus 45 days | None — anchored to departure, not to trip length |
The stay is the point. A component starting day 3 and running 3 nights covers days 3, 4 and 5; inserting a new day 4 means either a fourth night or a check-out and check-in. Both are legitimate, with different costs and cancellation terms, so a builder that picks one silently is wrong about half the time. Ask at the moment of insertion and record the answer as a change rather than an edit — the distinction that keeps a version, variant or revision legible.
A departure date is a property of the trip. A calendar date on a component is a copy of that property, and copies are where itineraries drift.
The cases that make people reach for dates anyway
- The overnight train. It starts on day 5 and ends on day 6. Model it as 1 component with a start offset and an end offset, shown on both days. Duplicating it onto each day is what makes an operations sheet request 2 vehicles.
- The arrival at 23:50. Day 1 has a hotel night and almost no usable time. Keep the night on day 1 anyway: the voucher must carry the check-in date the hotel is holding, not the date the traveller feels they arrived.
- The multi-timezone leg. Service dates are local to the service, not to the client. A flight leaving day 4 at 23:40 and landing day 5 at 06:15 has 2 local calendars, and both belong on the component.
- The template with no departure. This is the normal case, not the edge case, and it is why a component library composes cleanly while a dated template does not — the argument in templates or a component library.
- The payment schedule. Deposit and balance dates are anchored to departure, so they do not move when a day is inserted mid-trip, which is what stops the exposure examined in the balance is still unpaid in departure week.
The resolution rule, in one line each
- Store offsets. Every component holds a start day and, where it spans, an end day.
- Derive dates on read, against the departure and the local calendar. Deriving is cheap; reconciling 2 stored copies is not.
- Cache derived dates only on rendered documents, stamped with the revision they came from.
- Never write a derived date back onto a component. That one change turns this model into the one it was chosen to avoid.
- Re-derive and re-issue when a departure moves, treating every sent supplier request as needing re-confirmation rather than reprinting.
A first-week decision that sets what the tenth month can do — the pattern in how the trip data model sets the ceiling on quoting. Getting it right early is ordinary product build discipline, not clever engineering. The rest sits under itinerary building and the trip data model, in our travel and tourism practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Should itinerary days be stored as dates or as offsets from departure?
Store offsets and derive the dates. An offset lets the same itinerary exist as a template with no departure at all, and lets a departure move by changing 1 field rather than re-dating every component. Calendar dates should appear only where a document has been rendered for a client or a supplier, stamped with the revision it was produced from.
What happens to a multi-night hotel stay when a day is inserted?
It has to extend by a night or split into 2 stays, and the system must ask rather than choose. A 3-night stay starting on day 3 covers days 3 to 5; inserting a new day 4 either adds a fourth night or forces a check-out and a check-in. The 2 outcomes have different costs and different cancellation terms, so a builder that decides silently will be wrong about half the time.
How do you model an overnight service that spans two itinerary days?
As 1 component with a start offset and an end offset, displayed on both days. It remains a single purchasable service with one supplier, one reference and one cancellation term. Creating a copy on the second day is what makes an operations sheet double-count vehicles and a voucher pack contain a service nobody booked.
- data model
- itinerary
- dates
- templates
The work behind this page
Builds from our portfolio that this page draws on.
QuoteForge
An AI CPQ and proposal platform that builds enterprise quotes from your catalog, guards every discount against the margin floor, routes approvals, and generates the proposal.
Sales AINotewell
An AI meeting assistant that records and transcribes every meeting, extracts the decisions and action items, assigns owners and due dates, and tracks follow-through until it's done.
Productivity AIRead next
- The itinerary component: the smallest thing a trip can be built fromOne purchasable service carrying its own supplier, date, duration, pricing basis and cancellation term — and if it cannot be cancelled or repriced alone, it is a field on a component.definition
- Version, variant, revision: three itinerary objects, not oneA version is a snapshot, a variant is a parallel option, a revision is what the client has actually seen. Collapse them and the invoice, the proposal and the voucher start disagreeing.definition
- The client approved version four, and something movedA client quotes a detail your itinerary does not contain. Usually the builder edited in place and kept no snapshot, so the approved state has to be reconstructed from documents rather than read from the database.diagnostic
- Bookings confirm on your site and the supplier has no recordA confirmation email proves the checkout finished, not that a supplier accepted anything. Here is the timed comparison that shows whether your booking script reads live availability or a copy.diagnostic
- Drafts that put a closed property on day four: fixing seasonal blindnessSeasonal blindness is a metadata failure, not a prompting failure: the closure lives in a sentence nobody can filter on, so the shut property stays in the candidate set the model draws from.diagnostic
- Enquiry-to-booking conversion: the metric that lies at six monthsGroup enquiries by the month they arrived and follow them until they close. The calendar-month ratio moves when volume moves, so a growing month looks like a bad one.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation