That code runs in the context of humans. Therefore it needs to take humans into account when running.

This is a bit like asking "how do you represent a string length in utf-8?" The answer is, you don’t. It’s almost never a problem in practice.

Just like there is almost never a reason to care about the number of characters in a string, it’s very difficult to imagine that this code comes up in practice. But if it did, the code is simple: for a given timezone, is the current time in utc past 9:30am? If so, the store is open.

Let's say you host a store front for many businesses and it's decided that your customers, who are businesses, some with many stores, want to store a default opening time. Something along the lines of "All Home Depot's open a 6 AM, all Lowes open at 7 AM."

The store property would be "6 AM". Anywhere it’s used, it’s running in the context of humans. When displaying on a website, you don’t need to do any conversions: the human viewing the store knows where it’s located, and they know the current time, so computers don’t need to answer the question of whether it’s open.

If computers do need to know, then they’ll need to know a specific store with a physical location. That gives you the time zone.

> If computers do need to know, then they’ll need to know a specific store with a physical location. That gives you the time zone.

Mapping a location to a time zone seems fraught with peril. I’d store the local time zone explicitly.

Indeed. And anyone near a time zone boundary looking at an online map of store locations doesn’t want to see “opens at 6AM” or whatever — they want to know whether the store is open.

Indeed. It's not as bad as mapping address => sales tax (no ZIP Code isn't good enough), but only because it doesn't change as often and tends to follow county boundaries when it doesn't follow state boundaries.

Another good example. Arizona doesn't follow Daylight Savings, but the Navajo Nation, which includes the Four Corners area and is in three states, does observe the change.

However the Hopi reservation, completely surrounded by Navajo territory, is entirely in Arizona, and does not observe DST. So it can get quite complicated and it's not enough to say "Arizona doesn't have Daylight Savings Time".

There's no time zones involved in that at all. Nobody is going to be checking the opening hours of a Home Depot in another timezone and expect to get the date in their local timezone.

> Nobody is going to be checking the opening hours of a Home Depot in another timezone and expect to get the date in their local timezone.

You've never wanted to call a business in another timezone before making the trip out there?

...I can see this use case.

However, if I look up the opening time of a Home Depot in another time zone, I expect the result to be in that store's local time! I'll do the conversion myself. If I get my local time instead, I'll still perform the conversion, and get the wrong result.

You could just decide that any time listed anywhere on the internet should include a timezone... but that would be nuts.

I've never visited a brick and mortar store's website to check their opening hours and assumed it would be anything other than in their local timezone.

That’s not date data though. That’s just storing local time - 6 AM or 7 AM.

If someone expresses it that way it will be a huge hassle the moment they decide one store opens at a different time.

So maybe individual stores can customize their opening time, but corporate still wishes to store a default. How do you represent the default? How do you handle the DST time changes for individual stores?

I'm trying to poke holes in the "always use UTC and you're good" advice. I have actually encountered this scenario, and I didn't know how to apply that advice.

I don't get your problem, couldn't you store it like this: table timetable:

open | close | store 6am | 6am | default 7am | 12pm | store1

table stores: name | address store1 | xyx NYC

If you can't find the store in the timetable:

1. Get the timezone of the target store by looking up the address from the table stores

2. Set Hours from the default row in the timetable table on the object with the timezone

> I'm trying to poke holes in the "always use UTC and you're good" advice.

There's a much simpler one - recurring meetings/events (in-person or local-ish like within one country) that cross a DST boundary. You always want these to be attached to a local time zone, so it doesn't suddenly happen an hour earlier/later than you intended.

Where that gets even more fun is with international meetings, where the host of the meeting and the attendees are in different zones.

Postgres stores this as TIMESTAMP WITHOUT TIME ZONE, sometimes called wall-clock time. IMO this is a good convention -- treating "ideal times" and specific epoch moments as two different types -- and more languages should support this (ideally with a less confusing label).

Elixir does as well, with NaiveDatetime

utc is for a specific moment in time (deterministic with great precision for everyday use).

"9:30am local time" may be ambiguous/unknown (the rules may not exist yet)

Using the same programming type for both may cause confusion.

How do you express geographic coordinates? Noon in London and in NY are different moments in time (it may be important if you want to have a remote meeting).

No need for something as brittle as geographic coordinates or addresses. Time Zone names are the right abstraction. A given location very rarely time zone (unless in case of annexations, handovers of territory, etc.), but time zone rules (zone offset from UTC, DST, etc.) change all the time. A consequence of this is that the time zone database of applications should be updated every few months!

"brittle" ?

Your suggestion to define places by their timezone name is ok (it may work in many cases).

"Complicated" then. One would have to consult a map to find out the time zone from geographical coordinates. The time zone is really everything needed to properly perform timezone-aware arithmetic.

you don't, since they are different times?

Not sure if this is a serious question.

Each store will have an opening time, each will store the local time that the store opens.. just as utc.

Tuples of the local time zone (not utc offset) and a time, along with a utc localization conditional on date.

Reference opening time to local time on each day of the year, and then refer that back to UTC.

Like California is -8 in Standard, -7 in Daylight, so a 9:30 AM opening in the Winter is at 17:30 UTC, in the Summer, 16:30 UTC.

It's a hassle but programmers are supposed to model reality.

As an example of the problems that can arise, I remember when the new Japanese Emperor was to take office upon his father's abdication, there was a big fuss because the Era Name was customarily only revealed after the new Emperor's reign started but all the computer people wanted to be ready in advance. Not sure what finally happened, if it was revealed in advance or not.

What if the date for DST changes tomorrow, but only in some locations? How will you know which stores times need to be adjusted and which don't?

UTC to local time is not a function, it is not somethung that can be computed once and stored for the future. The two are fundamentally different concepts, and can only be related to one another in certain contexts, and only reliably for the past.

> How will you know which stores times need to be adjusted and which don't?

There are a number of libraries for this, usually updated by the unpaid volunteer in Nebraska. Or else your company has staff whose job it is to follow this for any place you operate.

If you record opening times as UTC, well, then you have to change to UTC when the store switches standard <=> daylight.

This is what Fred Brooks called an essential complexity. You can poke the pain from one part of your system to another part, but it's never going away.

The function is complicated. There is no avoiding that.

One Pacific island nation duplicated a calendar day when it switched International Dateline sides to more closely align with Australia instead of Hawaii, reflecting a shift in its economic ties. No idea how they handled it exactly but pretty hairy to model.

store_opening_hour_and_minute_of_day=(9,0)

It’s not a date time.

"9:30 AM every day" is not a datetime. It's a time.