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.

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.

For the info, I just fixed the time zone offset for Nepal in the algorithm. Check it out here https://thehtime.com/location?name=Nepal+-+Kathmandu and please let me know if it works.

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.

Sorry for that, I'll work on improving the cookie settings and experience.

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.

Thanks for the feedback! What are the confusing part except for the tabs? I'd love to work on that and improve it.

I just fixed the 30-min offset for Newfoundland, here is the fixed time https://thehtime.com/location?name=Canada+-+St.+John%27s

yes, that's the concept behind the letters. Cool day names btw!

Thanks! Yes I got the feedback on the responsiveness. I'll work on fixing thats.

:D I'll fix the cookie. Thanks for the feedback!

Not a bad idea at all. I'm sure we can tackle that. I actually played around with another concept as well which is using the Sun's location as our reference instead of UTC. This then gives our solar system a unified time, not only Earth. It's an incomplete concept still. I have it here in this blog post https://medium.com/adventures-in-consumer-technology/introdu... Would love to hear what you think.

Nice feedback! Well UTC date + time is the same here. It's then date + hTime ;) The need to add date is there anyway.

Thanks! What cities did you try? I'm happy to add them. And cool idea about the aliases, if you could give me some, I'll add them too.

Good feedback, thanks!

Ah got what you mean. Yes you're right. I'll think about a solution for that. Maybe some setting for the user to choose either a 24-hour or 12-hour system. It'll be challenging with the letter though, but I'll give it a shot.

Thanks for the clarification and feedback! As for the issues: - 0/O: I just fixed that by excluding I & O, and adding Y & Z. - Correct