3 ms·

The thing about the hour -- the part that's being abstracted away here -- is that (in most cases) it carries semantic meaning about daylight and thus about "wak

The thing about the hour -- the part that's being abstracted away here -- is that (in most cases) it carries semantic meaning about daylight and thus about "waking-world" and circadian-rhythm expectations. Yes, with timezones and UTC-offsets I have to keep in mind that 8:00 in my timezone might be 3:00 in someone else's timezone, but once I do the simple math of adding the offsets and doing any necessary modulos, I now know that the meeting time I've chosen almost certainly isn't a reasonable meeting time for that person. I know from experience that for the overwhelming majority of people in the world, 3:00 is still probably sleeping time, regardless of what timezone that 3:00 is in. 3:00 in UTC is sleeping time in London, 3:00 in UTC-5 is sleeping time in Atlanta, 3:00 in UTC+9 is sleeping time in Tokyo -- in any case, 3:00 is sleeping time. Attempts to have "one world timezone", even leaving out the existence of fractional-hour timezone offsets, will always throw away that semantic detail about human schedules. For example, let's say you just enforce that everyone uses UTC. Congratulations, you no longer have to do offset math. Except that you have no idea if 10:00 is a reasonable meeting time for anyone within a few timezones of you (which remember, no longer exist, so you can't really use them as references). You no longer have to memorize each participant's offsets, but now you have to memorize the daylight hours for each participant instead, and that's arguably harder (X's daylight hours are 8:00->16:00, but Y's daylight hours are 14:00->2:00, but then Z's daylight hours are 12:30->20:30). Yes, there are companies with overseas contracts who dedicate some staff to working the same hours as their overseas counterparts. Do we really want that to become the global norm, though? Because if not, then "daylight hours" remains an important concept, and it's already baked semantically into the system of timezones we have today, more simply than the alternative. So if we toss out the piece of information that conveys the detail about "daylight hours" (which is what this clock does with its letters-instead-of-hours), then we're losing that information, and making it much easier to trample all over somebody's reasonable working schedule.

nixpulvis 5y ago
Nobody is talking about removing local times, otherwise this tool wouldn't even need to exist.
- hhebbo 5y ago
  Correct
zamadatix 5y ago
What's the obsession with knowing which daylight hour offset it would be for someone else? Wouldn't you rather know a range of hours that works for them rather than a range of hours you assume they'll be awake (and hopefully not busy)? If the position of the sun is truly important to your use case then knowing a location is "UTC+9" as far as sunshine hours go is still able to tell you that without requiring you encode that information into the time value itself.
- fao_ 5y ago
  > What's the obsession with knowing which daylight hour offset it would be for someone else? This is already answered in the post you are replying to, so I assume this is you demanding an external source: https://www.wikiwand.com/en/Circadian_rhythm https://www.wikiwand.com/en/Circadian_rhythm https://www.wikiwand.com/en/Sleep https://www.wikiwand.com/en/Sleep
  - zamadatix 5y ago
    My inquiry was not about or asking for proof of the idea people sleep at night rather why that info is preferred over more salient information as seen by continuing to the following, unquoted, sentence.
  - kaishiro 5y ago
    I don't believe parent was "demanding" anything. Simply asking an increasingly relevant question as work moves from office to home and the remote work pool expands.
hhebbo 5y ago
Thanks for the detailed explanation. But as nixpulvis said, the clock doesn't remove the local times and replace them with UTC. That's not the idea. The clock actually brings the best of both local times and UTC together in one clock. Local times are here to stay with UTC. What the clock is that it maps them together by rotating the UTC layer (in letters) so the reading of time is the same everywhere for everyone. I hear you on waking time. For that I've build the "Meeting Time" feature that makes sure to find the best time for a meeting for different locations where it's a good time to meet for everyone. For example, the best time to have a meeting between San Francisco, New York, London, and Berlin is between P-R baring in mind that the clock makes sure that the meeting is between 8am and 19 (7pm) for everyone. And this is all configurable :) You can also share the link of the meeting time as this one https://thehtime.com/intersect?locations=USA+-+San+Francisco%2CUSA+-+New+York%2CUK+-+London%2CGermany+-+Berlin https://thehtime.com/intersect?locations=USA+-+San+Francisco... Happy to hear your thoughts on this feature.
- ubertaco 5y ago
  >The clock doesn't remove the local times and replace them with UTC You're right, this clock doesn't remove the local times and replace them with UTC; instead this clock overlays the local times with a replacement "A-X time", which is a single timezone applied to everywhere. Not UTC, but a new, non-standardized "DIY" UTC. That's the whole thing it does: throw away the location-specific "daylight-hours" quantifier (the "hour" part of the time) and replace it with a "single timezone" version (where it's "F:30" everywhere on earth at the same time), but instead of the globally-recognized standard of UTC, it's a brand-new standard that arbitrarily uses letters rather than numbers (with an "origin point" that's unclear -- where in the world is A:00 equal to 00:00? I couldn't find it, so I couldn't easily figure out my timezone's offset so that I could reason about daylight hours). I've seen clocks that do this already, but with UTC instead of "A-X time": they have two "dials", one for local time and one for UTC. That's all this is, just with letters instead of numeric hours (an arbitrary substitution) and a newly-made-up "base" timezone instead of UTC. There's no functional difference between consulting a clock like this so that you can say "F:30" to all of your teammates and it'll be the same time everywhere, and consulting a UTC clock so that you can say "10:30 UTC" to all of your teammates and it'll be the same time everywhere, except that most people have memorized their local UTC offset and can go "oh, okay, 10:30 - 5 hours = 5:30", where with F:30 they have to go consult your website instead. Having a configurable "meeting time" feature is neat, but like...that's an extra tool you had to build on top of your clock system, not an intrinsic feature of your clock system itself. I need a complex translator tool to tell me what A-X hours are reasonable for meeting with people because I can't just simply apply offsets in my head and get intuitive results (especially because the "base" offsets are unclear). I think a lot of folks overestimate how painful it is to do modulo addition/subtraction, compared to how painful it is to learn an entirely new system of timekeeping-and-translation.

nixpulvis 5y ago

Nobody is talking about removing local times, otherwise this tool wouldn't even need to exist.

hhebbo 5y ago
Correct

zamadatix 5y ago

What's the obsession with knowing which daylight hour offset it would be for someone else? Wouldn't you rather know a range of hours that works for them rather than a range of hours you assume they'll be awake (and hopefully not busy)? If the position of the sun is truly important to your use case then knowing a location is "UTC+9" as far as sunshine hours go is still able to tell you that without requiring you encode that information into the time value itself.

fao_ 5y ago
> What's the obsession with knowing which daylight hour offset it would be for someone else? This is already answered in the post you are replying to, so I assume this is you demanding an external source: https://www.wikiwand.com/en/Circadian_rhythm https://www.wikiwand.com/en/Circadian_rhythm https://www.wikiwand.com/en/Sleep https://www.wikiwand.com/en/Sleep
- zamadatix 5y ago
  My inquiry was not about or asking for proof of the idea people sleep at night rather why that info is preferred over more salient information as seen by continuing to the following, unquoted, sentence.
- kaishiro 5y ago
  I don't believe parent was "demanding" anything. Simply asking an increasingly relevant question as work moves from office to home and the remote work pool expands.

hhebbo 5y ago

Thanks for the detailed explanation. But as nixpulvis said, the clock doesn't remove the local times and replace them with UTC. That's not the idea. The clock actually brings the best of both local times and UTC together in one clock. Local times are here to stay with UTC. What the clock is that it maps them together by rotating the UTC layer (in letters) so the reading of time is the same everywhere for everyone. I hear you on waking time. For that I've build the "Meeting Time" feature that makes sure to find the best time for a meeting for different locations where it's a good time to meet for everyone. For example, the best time to have a meeting between San Francisco, New York, London, and Berlin is between P-R baring in mind that the clock makes sure that the meeting is between 8am and 19 (7pm) for everyone. And this is all configurable :) You can also share the link of the meeting time as this one https://thehtime.com/intersect?locations=USA+-+San+Francisco%2CUSA+-+New+York%2CUK+-+London%2CGermany+-+Berlin https://thehtime.com/intersect?locations=USA+-+San+Francisco... Happy to hear your thoughts on this feature.

ubertaco 5y ago
>The clock doesn't remove the local times and replace them with UTC You're right, this clock doesn't remove the local times and replace them with UTC; instead this clock overlays the local times with a replacement "A-X time", which is a single timezone applied to everywhere. Not UTC, but a new, non-standardized "DIY" UTC. That's the whole thing it does: throw away the location-specific "daylight-hours" quantifier (the "hour" part of the time) and replace it with a "single timezone" version (where it's "F:30" everywhere on earth at the same time), but instead of the globally-recognized standard of UTC, it's a brand-new standard that arbitrarily uses letters rather than numbers (with an "origin point" that's unclear -- where in the world is A:00 equal to 00:00? I couldn't find it, so I couldn't easily figure out my timezone's offset so that I could reason about daylight hours). I've seen clocks that do this already, but with UTC instead of "A-X time": they have two "dials", one for local time and one for UTC. That's all this is, just with letters instead of numeric hours (an arbitrary substitution) and a newly-made-up "base" timezone instead of UTC. There's no functional difference between consulting a clock like this so that you can say "F:30" to all of your teammates and it'll be the same time everywhere, and consulting a UTC clock so that you can say "10:30 UTC" to all of your teammates and it'll be the same time everywhere, except that most people have memorized their local UTC offset and can go "oh, okay, 10:30 - 5 hours = 5:30", where with F:30 they have to go consult your website instead. Having a configurable "meeting time" feature is neat, but like...that's an extra tool you had to build on top of your clock system, not an intrinsic feature of your clock system itself. I need a complex translator tool to tell me what A-X hours are reasonable for meeting with people because I can't just simply apply offsets in my head and get intuitive results (especially because the "base" offsets are unclear). I think a lot of folks overestimate how painful it is to do modulo addition/subtraction, compared to how painful it is to learn an entirely new system of timekeeping-and-translation.