4 ms·

How do you express "our stores, across 6 different timezones, all open at 9:30 AM local time" in UTC?

by Buttons840 3y ago

pelorat 3y ago
you don't, since they are different times?
- deleted 3y ago
  [deleted]
sillysaurusx 3y ago
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.
- Buttons840 3y ago
  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."
  - wayfinder 3y ago
    That’s not date data though. That’s just storing local time - 6 AM or 7 AM.
  - sillysaurusx 3y ago
    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.
    - macintux 3y ago
      > 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.
      - amluto 3y ago
        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.
      - JJMcJ 3y ago
        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".
  - efdee 3y ago
    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.
    - blincoln 3y ago
      > 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?
      - efdee 3y ago
        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.
      - Wowfunhappy 3y ago
        ...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.
- deleted 3y ago
  [deleted]
joshspankit 3y ago
If someone expresses it that way it will be a huge hassle the moment they decide one store opens at a different time.
- Buttons840 3y ago
  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.
  - bpfrh 3y ago
    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
  - Izkata 3y ago
    > 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.
    - fragmede 3y ago
      Where that gets even more fun is with international meetings, where the host of the meeting and the attendees are in different zones.
bofaGuy 3y ago
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.
d0mine 3y ago
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).
- samus 3y ago
  No need for something as brittle as geographic coordinates or addresses. Time Zone names are the right abstraction. A given location very rarely [edit: adopts another] 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!
  - d0mine 3y ago
    "brittle" ? Your suggestion to define places by their timezone name is ok (it may work in many cases).
    - samus 3y ago
      "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.
Footkerchief 3y ago
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).
- kevindamm 3y ago
  Elixir does as well, with NaiveDatetime
dumah 3y ago
Tuples of the local time zone (not utc offset) and a time, along with a utc localization conditional on date.
JJMcJ 3y ago
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.
- tsimionescu 3y ago
  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.
  - JJMcJ 3y ago
    > 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.
konschubert 3y ago
store_opening_hour_and_minute_of_day=(9,0) It’s not a date time.
remram 3y ago
"9:30 AM every day" is not a datetime. It's a time.

How do you express "our stores, across 6 different timezones, all open at 9:30 AM local time" in UTC?

pelorat 3y ago

you don't, since they are different times?

deleted 3y ago
[deleted]

sillysaurusx 3y ago

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.

Buttons840 3y ago
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."
- wayfinder 3y ago
  That’s not date data though. That’s just storing local time - 6 AM or 7 AM.
- sillysaurusx 3y ago
  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.
  - macintux 3y ago
    > 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.
    - amluto 3y ago
      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.
    - JJMcJ 3y ago
      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".
- efdee 3y ago
  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.
  - blincoln 3y ago
    > 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?
    - efdee 3y ago
      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.
    - Wowfunhappy 3y ago
      ...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.
deleted 3y ago
[deleted]

joshspankit 3y ago

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

Buttons840 3y ago
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.
- bpfrh 3y ago
  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
- Izkata 3y ago
  > 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.
  - fragmede 3y ago
    Where that gets even more fun is with international meetings, where the host of the meeting and the attendees are in different zones.

bofaGuy 3y ago

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.

d0mine 3y ago

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).

samus 3y ago
No need for something as brittle as geographic coordinates or addresses. Time Zone names are the right abstraction. A given location very rarely [edit: adopts another] 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!
- d0mine 3y ago
  "brittle" ? Your suggestion to define places by their timezone name is ok (it may work in many cases).
  - samus 3y ago
    "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.

Footkerchief 3y ago

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).

kevindamm 3y ago
Elixir does as well, with NaiveDatetime

dumah 3y ago

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

JJMcJ 3y ago

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.

tsimionescu 3y ago
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.
- JJMcJ 3y ago
  > 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.

konschubert 3y ago

store_opening_hour_and_minute_of_day=(9,0) It’s not a date time.

remram 3y ago

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