Not for using the clock no, charging people for reading time would be ridiculous :) The clock is only the first step to simplify time zone thinking. If people like to use this, I do have plenty of ideas on what to build on top of this.
> Not for using the clock no, charging people for reading time would be ridiculous
Agree, what about the other tools on the website, that is using the new time format you've created, are they within the patent too? It's really unclear what the patent is covering, and unfortunately your comment didn't help.
Sorry I can't disclose what the patent is covering for now, but I can say it's mainly about the IP. Are you planning to use hTime? I'm happy to chat about it if you like to.
Yes, I'm working with multiple organizations that are suffering from the problem it aims to solve, but the vagueness of the patent and lack of transparency would make it very hard to even start talking about it.
Done! Thanks for the feedback!
This makes sense, I've received this feedback several times today.
Would you like to give hTime a go and test it for some days? I'd love to hear some more feedback.
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...
>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.
I appreciate the detailed analysis. The base of the letters and where they start, the A, is UTC. A is UTC +/-0. The idea isn’t the letters, which seem to be the main point in the comment, the idea is the rotating UTC (represented by letters to distinguish local from UTC times) instead of having am extra hand moving. An extra Hand moving will make the clock more complex to read. We’d have 4 hands moving. I think a rotating UTC makes it easier to read. As for the letters, it’s easy to change back to numbers which is then simply UTC itself. It’s an experiment with letters, if it doesn’t work, it can be changed.
Would love to hear your thoughts on the rotating UTC layer vs an extra UTC layer + hand.
Not at all, thanks for asking and the nice wishes ;)
The Internet Time, Beats, is a completely new time/clock system. It’s unclear what 964 for example means. With this clock, I’m using the same time/clock system we all know well: 24 hours, 60 minutes, 60 seconds. The addition to that is UTC. Why? To make the clock show the global time as well, and then map the local time with the global time together in one clock face. By this, we can always be in sync locally and globally. The UTC layer in the middle is represented by letters to simply distinguish global from local times. This layer rotates with users according to their location on Earth. Why? To unify the reading of time when doing the mapping, so the reading of time is always the same no matter where users are. I understand that the letters might be confusing a bit, but this can be fixed easily by replacing them with numbers again.
Here is an example: 2 days ago there was the Apple event. It was at 10am PDT. I’m not sure what that is in my local time and other local times. If that event would be translated to hTime, it would be at R:00. No matter where we are, we can see the local and global hours for R:00, so no time zone calculations are needed any more.
I believe the barrier-to-entry with a 24-hour, 60-minute, 60-second system is simpler than Beat.
Well, the clock is UTC. That's the whole concept :) The clock simply combines our local times with UTC in one clock face. To make UTC work for all time zones, it also rotates UTC according to your location on Earth. This means that the reading of time is the same everywhere at any time using the rotated UTC. The clock's algorithm also automatically takes care of all time changes, keeping the reading of time consistent globally.
We actually can't just use UTC as is and eliminate time zones completely. If we do so, people in some places would go to work at 2am, in other places at 8pm. That's even more confusing. So the clock of hTime aims to use the best of both local and global times worlds in one clock interface.
As for day-changing, I hear you. Again this is UTC, so what the day of UTC is is the day of hTime. Something to work more on indeed.
The number on the clock is by convention, I used to go to work at 2am, I worked nights.
If everyone just published hours in UTC, and availability in UTC, this would work fine. You'd know that normal working hours for your area are you know, 1200-2000 UTC.
Makes sense, that would also work. However, there is another case where the question comes: what is the best time for a meeting between San Francisco, New York, London, and Berlin for example? Here it becomes a bit challenging as we lost the meaning of local hours for those locations. 2am in most cases means sleeping time, not for everyone, but mostly. With only UTC we'd lose the semantics meaning of local hours. Hence combining local hours and UTC in one clock face.
> We actually can't just use UTC as is and eliminate time zones completely. If we do so, people in some places would go to work at 2am, in other places at 8pm. That's even more confusing.
If we adopt hTime, people in some places would go to work at C:00, and in other places at U:00. What’s the difference, really? If you say that people in London think that 8-4 UTC (now 9-5 BST) are working hours and would be confused their NYC colleagues would say they are working 4-12 (now 9-5 EDT), then you get the same “confusion” if London thinks I-Q and NYC says N-V.
You're right :) The concept is to use both together. And that's what the clock is doing. It keeps local times, and adds UTC as a global time, then maps them together with location-offset-based rotating.
Great feedback! Yes, that's exactly the concept of letters and numbers for local and global times :) I'll work more on the responsiveness of the interface. There is something to improve every day.
Do you work across time zones? If yes, would you like to give hTime a go and test it for some days? I'd love to hear more feedback from daily usage of the clock.
Not anymore. Within a few hours, it's easy to accommodate in my head. But, spanning continents, it's a lot harder. I'm generally in the habit of always saying the time zone when talking across timezones.
BTW: Have you ever written a Fitbit watchface? They're pretty easy.
Your firm should use hTime then for scheduling :D They could use the "Meeting Time" https://thehtime.com/intersect feature to make sure it's a good time for everyone.
You're right. Firstly, I don't really understand why those countries decided to go with a 30-minute offset. It's adding even more confusion to the whole time zone and daylight saving thing. hTime utilizes UTC, hence the 30 minutes difference. However, that's something to think more about and see how to fix it properly. Thanks for the feedback.
Would you give hTime a go and test it for some days? I'd love to hear more feedback.
This just shows you didn’t even do the basic background research before jumping head-first into this idea (not to mention blaming the countries). Why would someone try your app knowing full-well it is fundamentally broken?
I appreciate your candor feedback. When users worldwide use the clock, they'll see both global and local times in one place, the global time will be "without" the minutes offset, and the local time will be "with" the minutes offset, so the mapping does actually work and I don't think it's broken in that sense. And as any project, there's always room for improvement.
The mapping is clear, and I think many of us get it that anyone in any time zone can look at the mapped clock and see the same time.
As well, I personally think that building on UTC but making it clearly recognizable is a clever approach (avoiding, as you say; “Meet me at to 2PM UTC.” being quickly internalized in someone’s brain as 2PM local time), but there are too many (known) edge cases that this cannot solve (such as arbitrarily-numbered minute offsets, and possibility of confusing dates when setting the time)
When OP talked about it being broken, I suspect they meant something like “With enough knowledge of the complexities of international timezones, as well as the psychology internal to administrators and the public, it is clear that this specific approach cannot solve the problem for everyone world wide without an amount of amount of public shift that is borderline impossible. (For reference, see the XKCD comic about creating a unifying standard)”.
It's definitely challenging to influence people's behavior especially when it comes to something so essential like time and the clock. However, I believe dealing with time zones when working with distributed teams is actually more challenging. I can't count the times people missed a meeting or a deadline by an hour because they miscalculated time zones, hence the work on hTime.
If I (in a timezone with an even number of hours offset) schedule a meeting at S:30, what time is someone from St John's going to show up? (I think half an hour late?)
What I mean is for example: India as you mentioned above in the list. On hTime https://thehtime.com/location?name=India+-+Mumbai the local time is with a 30-minute offset, and the global isn't following UTC.
For St. John's offset, I actually wasn't aware of it, from the data I have it seemed to me that Canada in general doesn't have that. But worry not, I just fixed it on the website and added it to the algorithm offsets, please check again and let met know what you think. Here is the link to St. John - Canada https://thehtime.com/location?name=Canada+-+St.+John%27s
If a meeting is scheduled using hTime, then it'll be in hTime with half an hour offset from the local hour in St. John.
