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.
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.
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".
You've never wanted to call a business in another timezone before making the trip out there?
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'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.
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.
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
"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).
Your suggestion to define places by their timezone name is ok (it may work in many cases).
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.
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.
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.
It’s not a date time.
Each store will have an opening time, each will store the local time that the store opens.. just as utc.