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.
Does Zulu tone have a tool to intersect different times together to find the best time? So it makes sure that’s it’s in a range of good times to meet. Like normal working hours from 7-8 to 18-19. That’s what would be import with finding the best time and where hTime’s clocks becomes more useful. But that also could be implemented in Zulu I believe.
The feedback and arguments are highly valuable. I really like the way of thinking about time zones in your explanation.
As you mentioned, hTime is a time format and a tool, which I like describing as a "clock". A clock combines both concepts. Clocks is a way to measure, read, and communicate time. With hTime, that's the goal. Now with the formatting piece from your examples "2021-10-20+5-03:36, 2021-10-20Z22:36, 2021-10-20Q:36", all of them actually look and read the same somehow. To be honest, Z22 or Q isn't that big of a difference IMHO. The difference is the math still. It's very simple math, just adding or subtracting, but it gets confusing when more than one time zones are involved. Take a meeting between 2+ time zones. The question then is: What is the best time to have a call between 3 different locations? The math, as simple as it is, get a bit confusing to find the best time. I've been in several situations and heard that many users of time zones miss a call by +-1 hour only because they miscalculated time zones.
The other aspect is time communication. That's the case when a deadline or an event is happening somewhere around the world. We usually communicate time using 3-4-lettered time zone names that make it even harder to remember. For example the Olympics, there was a game at 2pm Tokyo time; what is that for the rest of the world? Before doing the math, we need to know what Tokyo's time zone is, what the Z or UTC equivalent is, and then do the simple math. It's almost always a 2-step thing. With hTime as a clock, it's only the mapping. So if they say the game is at R:00, I have the mapping in my head and done! 1 step. With the example of a meeting between 3 time zones, that's then 5-6 steps with Z or UTC, but with hTime, it's again 1 step only. That's the kind of thinking I have behind "no more time zone math" and the idea of hTime's clock with the mapping between global and local times.
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.
The idea is not to abolish time zones, the idea is to add UTC to the clock so we have local times (time zones) and a global time (UTC) in one clock. With added features like "Meeting Time", we can defiantly find the best time to call and making sure it's not 4am in the other place.
Thanks, orbital time isn't final yet. Those are the initial thoughts to solve it. The approach of using the Sun's location might work.
Yes, many corner cases, but somebody has got to solve them, this is the start.