4 ms·

Great feedback, thanks! Probably the letters makes it harder to comprehend. Actually there is no difference that writing 14:15Z. The main concept is to map UTC,

by hhebbo 5y ago

Great feedback, thanks! Probably the letters makes it harder to comprehend. Actually there is no difference that writing 14:15Z. The main concept is to map UTC, or Zulu, to our local times in one clock where UTC rotates according to your location on Earth. So all users when they look at the clock at the same time no matter where they are, they'd see the same time. It's a global clock idea. I can simply change the letters to numbers, do you think that'd help?

joshspankit 5y ago
If changing the letters to numbers, you’re coming down to advocating that everyone use UTC for coordination which makes hTime just a handy tool and not a solution
- hhebbo 5y ago
  True. I'm actually fine with that. Main thing is we find a good way to get rid of time zone math! :)
nixpulvis 5y ago
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.
- 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.

by hhebbo 5y ago

joshspankit 5y ago

If changing the letters to numbers, you’re coming down to advocating that everyone use UTC for coordination which makes hTime just a handy tool and not a solution

hhebbo 5y ago
True. I'm actually fine with that. Main thing is we find a good way to get rid of time zone math! :)

nixpulvis 5y ago

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.

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.