hhebbo

That's an interesting use case! :)

Got it, makes sense. Thanks!

How would that work, can you elaborate more please?

That’s neat!

Oh I see, that’s a tough one. And thanks for the feedback!

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.

Love the idea of the animation! I'll do it.

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.

Happy to hear what you think

We gotta start somewhere and improve on the go :)

Yes, it still needs more cooking, I'd love to hear more thoughts on that. We might need such a concept for a multi-planetary clock.

For a few hours and one time zone, you're right it's easy. The confusion starts for me with 2+ time zones in one call/event.

I'm thinking about starting with an Apple watch, Android watch first, but I'll check the Fitbit one and build after the apple one, cool idea!

yeah :)

Good idea! I had it before and removed for simplicity, but I'll put it back. You're right, it'll help with the edge cases.

Got it, will do in the next couple of days. Thanks for the suggestion.