Your Business Runs on Texas Time. Store It in UTC Anyway.

Your customers live on Texas time.

Your database should not.

Three weeks from today, on Sunday, November 1, 2026, daylight saving time ends. Per NIST, at 2:00 a.m. local time the clock goes back to 1:00 a.m. and that hour happens twice.

Most small business owners will not notice.

Their systems will.

Two clocks, two jobs

Every business system has two kinds of time in it.

Human time. When the reminder goes out. When the shop opens. When the follow-up text lands. People live here, so this belongs in your local zone.

Machine time. When a lead came in. When an invoice was paid. When a record changed. This is the order of events, and it must never jump, repeat, or skip.

Mix those two up and you get bugs that only show up twice a year.

How I run mine

Here is what that buys me.

Today, 06:05 Central is 11:05 UTC. After November 1, 06:05 Central is 12:05 UTC.

The timer follows the wall clock. My articles still go out at 06:05 on a Monday in November, the same as a Sunday in October. I do not touch anything.

Meanwhile every published time in the database is UTC. Sorting never breaks. Nothing looks like it happened before the thing that caused it.

The timer is plain systemd, which accepts a zone name from the IANA time zone database right on the schedule line. No custom code. No reminder on my calendar to go fix it twice a year.

The three mistakes I look for

When I audit somebody's setup, these are the ones I find.

1. A fixed offset pretending to be a zone. Somebody typed "minus five" into a setting in the summer. It was right in July. It is an hour off all winter. Use the zone name, America/Chicago, not the offset.

2. Jobs scheduled between 1 and 3 a.m. That window is where the clock jumps. In November the 1 a.m. hour repeats. In March the 2 a.m. hour does not exist. Some schedulers run a job twice, some once, some skip it. Find out which yours does, or just keep your jobs out of that window.

3. Local time stored as the record. If a lead form saves "1:30 a.m." with no zone on November 1, you cannot tell which 1:30 it was. Store UTC. Convert to local only when a human reads it.

Do this before November 1

Open your booking tool, your CRM, and anything that sends automatic texts or emails.

For each one, answer two questions.

What zone does it schedule in?

What zone does it store in?

If you cannot answer, that is your answer. Find out this week, not on November 2 when a customer asks why their reminder showed up an hour early.

Owning your platform is not only about owning the data.

It is knowing what your system does at 6 a.m. while you are still asleep.