I was actually arguing that the letter makes it easier to comprehend in a sense, because it forces you to do the mapping, instead of assuming the same zone.
That being said, the interface should really put the location closer to the letter ring, because it's somewhat easy to forget you're looking at a localized mapping and what the letters mean, since they are in another UI element.
"So all users when they look at the clock at the same time no matter where they are, they'd see the same time."
This is true of any clock (unless fancy optics are involved, or we get too deep into physics), two people looking at the same wall clock will see the same time. The problem is that they might want to interpret what they see in a different way. Both UTC and your htime thing are a way to solve that problem.
Leading with a letter helps people not start reading as a local time, whereas with 8061 formatted times you only notice it's not in your own locale at the very end of the time. Depending on your use one might be better than the other. Unfortunately time requires that I remember one additional piece of information, namely UTC: X=24, before I can index into the alphabet and calculate the difference myself, whereas UTC simply requires I add the offset to the time and move on with my life.
What I actually meant by "all users when they look at the same clock at the same time" is all users in different locations would see that time is the same in letters. For example everybody worldwide would see that time now is R:24.
I agree on the last piece as well. I think using it for some time will prove what would be better for the UTC ring, letters or numbers. Each has its own benefits and flaws as you mentioned.
Would you like to give hTime a go and test it for some days? I'd love to hear some more valuable feedback.
I actually had a really simple idea that would have helped me a lot while discovering the tool. I hate most animations, however smoothly rotating the ring would do wonders for people understanding what's going on here. You just need to decide which way to rotate ;)
> Would you like to give hTime a go and test it for some days?
Perhaps... but to be perfectly honest, I haven't yet decided if I love or hate this idea yet.
To give you an idea about how I'm thinking of this, first and foremost hTime is a time format, meaning it's just some mapping of letters to a local time's hour. The most interesting part to me is that, since I read left to right, I also see the locale information first as opposed to last. You can rightfully argue that the locale is needed to interpret the rest of the time, so this is the correct way to format world times. On the other hand, world times are the same as local times for everyone within earshot of me, so I would never bother prefixing things locally.
Secondly, it's a tool for helping people with world clocks and scheduling.
My concern is that there are better solutions to the first thing, despite any improvements made to the second. For example, would it not be better to simply prefix the timezone information directly? For example, it's currently Z22:36. We do use more characters, especially if we want to be able to extend this to local times too (e.g. +5-03:36). I might be tempted to start trying to lay this out so the math works out for (+5) adding directly to the hour as 5+03:36 = Z22:36, but now I realize a larger problem with all this... dates.
Placing the offset in the middle of the full time string 2021-10-20 together with 22:36 requires thought. I'm tempted to like it, because the timezone offset is obviously much more related to the time than the date, but moving it closer to the date really couldn't hurt, could it?
Take either hTime, or my example:
- 2021-10-20+5-03:36
- 2021-10-20Z22:36
- 2021-10-20Q:36
We just replace the 'T' in ISO-8601 with the 'Z' part or with nothing before an hTime. Now I get to complain that 'Z' looks way too much like 2... Meanwhile https://thehtime.com/ hasn't loaded and I can't remember the mapping for the current time, so I don't think I've written my example consistently.
I think that's the part of hTime I like the least. I have no hope of decoding it without knowing what it is. Meanwhile an 8601 datetime stamp can be somewhat inferred. So to quote you, if I may, "[the] main thing is we find a good way to get rid of time zone math!". But we can't get rid of the time zone math... it's just either arithmetic, or a special code.
Anyway, I'm just bored right now over here thinking on paper. Always glad to hear that my feedback is somewhat useful. Thanks.
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.
> The question then is: What is the best time to have a call between 3 different locations?
ZXX:XX surely. For example, we could meet at Z1340 even. To me this is a question making the string unique enough that people won't accidentally think of it as a local time. The military uses 24-hour times in a similar manar, e.g. "Oh-seven-hundred", etc. So aside from Z13:40 possibly looking too close to just 13:40, it does communicate the time for people to meet, regardless of how many timezones are involved. What's the best time to meet is a whole other question...
I honestly haven't even started to think about how this integrates with DST and other funky locale calendar rules.
I'm going to be busy for a bit, but hopefully I remember to come back to this thread...
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.
That being said, the interface should really put the location closer to the letter ring, because it's somewhat easy to forget you're looking at a localized mapping and what the letters mean, since they are in another UI element.
"So all users when they look at the clock at the same time no matter where they are, they'd see the same time."
This is true of any clock (unless fancy optics are involved, or we get too deep into physics), two people looking at the same wall clock will see the same time. The problem is that they might want to interpret what they see in a different way. Both UTC and your htime thing are a way to solve that problem.
Leading with a letter helps people not start reading as a local time, whereas with 8061 formatted times you only notice it's not in your own locale at the very end of the time. Depending on your use one might be better than the other. Unfortunately time requires that I remember one additional piece of information, namely UTC: X=24, before I can index into the alphabet and calculate the difference myself, whereas UTC simply requires I add the offset to the time and move on with my life.