Everything is civil time
A collection slot is not a moment in time. It is a thing written on a board behind a counter: Saturday, half past nine.
So this app stores dates as YYYY-MM-DD and times as HH:MM, both as text,
both read as the shop’s wall clock. No Date arithmetic is used for the
calendar at all.
That sounds like the naive approach. It is the opposite. It is what stops a
shopper in another timezone, or a British Summer Time changeover, from
silently shifting a slot the shop has already published. If a nine o’clock
collection is a Date, a customer opening the page in Madrid gets ten, and a
slot created in October is an hour out in November. Nobody notices until
somebody turns up at the wrong time — and then it is not a bug report, it is
a person standing at a counter.
The date is stored as text for a second reason too: it sorts chronologically as a string, and cannot be shifted by a timezone conversion on the way into or out of the database.
The same reasoning runs through the market stalls feature. A nine o’clock market is at nine whatever the clocks do, so those dates and times are text as well.
This is one of those decisions that looks like laziness in review and turns out to be the single largest source of avoided bugs in the project. The general form: if the domain concept is a wall-clock reading, storing an instant is a lossy conversion. You can always derive an instant from a civil time and a place. You cannot reliably get the civil time back.