4 ms·

Got what you mean, I'll work on the letter ring. What I actually meant by "all users when they look at the same clock at the same time" is all users in differe

by hhebbo 5y ago

Got what you mean, I'll work on the letter ring. 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.

nixpulvis 5y ago
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/ 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.
- hhebbo 5y ago
  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
  - nixpulvis 5y ago
    > 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...

by hhebbo 5y ago

nixpulvis 5y ago

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/ 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.

hhebbo 5y ago
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
- nixpulvis 5y ago
  > 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...