Show HN: Combining UTC and local times (time zones) in one new clock(thehtime.com)
thehtime.com
Show HN: Combining UTC and local times (time zones) in one new clock
https://thehtime.com
200 comments
It's like UTC but worse. If people need to learn something new, it's better to teach the basics of ISO 8601 to everyone.
Intentions are good, but I found this system confusing and not useful for me.
I use to use Everytimezone, but find Dateful's dual timezone display more useful for my needs.
https://dateful.com/time-zone-converter
Edit: Added positive remark about good intentions.
I use to use Everytimezone, but find Dateful's dual timezone display more useful for my needs.
https://dateful.com/time-zone-converter
Edit: Added positive remark about good intentions.
Thanks for the feedback, I appreciate it! May I ask why do you find it confusing? I’d love to improve it.
Well, the clock is UTC. That's the whole concept :) The clock simply combines our local times with UTC in one clock face. To make UTC work for all time zones, it also rotates UTC according to your location on Earth. This means that the reading of time is the same everywhere at any time using the rotated UTC. The clock's algorithm also automatically takes care of all time changes, keeping the reading of time consistent globally.
We actually can't just use UTC as is and eliminate time zones completely. If we do so, people in some places would go to work at 2am, in other places at 8pm. That's even more confusing. So the clock of hTime aims to use the best of both local and global times worlds in one clock interface.
As for day-changing, I hear you. Again this is UTC, so what the day of UTC is is the day of hTime. Something to work more on indeed.
We actually can't just use UTC as is and eliminate time zones completely. If we do so, people in some places would go to work at 2am, in other places at 8pm. That's even more confusing. So the clock of hTime aims to use the best of both local and global times worlds in one clock interface.
As for day-changing, I hear you. Again this is UTC, so what the day of UTC is is the day of hTime. Something to work more on indeed.
Why cant we?
The number on the clock is by convention, I used to go to work at 2am, I worked nights.
If everyone just published hours in UTC, and availability in UTC, this would work fine. You'd know that normal working hours for your area are you know, 1200-2000 UTC.
The number on the clock is by convention, I used to go to work at 2am, I worked nights.
If everyone just published hours in UTC, and availability in UTC, this would work fine. You'd know that normal working hours for your area are you know, 1200-2000 UTC.
I'll just leave my common advice here.
- Store all dates and times as UTC when dealing machine interfaces
- Communicate to others as clearly as concisely as possible.
So, I store everything in Postgres as ISO-8601 UTC times, while I tell my friends I'll be there at 8 (even though my watch will say 20:00).
- Store all dates and times as UTC when dealing machine interfaces
- Communicate to others as clearly as concisely as possible.
So, I store everything in Postgres as ISO-8601 UTC times, while I tell my friends I'll be there at 8 (even though my watch will say 20:00).
Makes sense, that would also work. However, there is another case where the question comes: what is the best time for a meeting between San Francisco, New York, London, and Berlin for example? Here it becomes a bit challenging as we lost the meaning of local hours for those locations. 2am in most cases means sleeping time, not for everyone, but mostly. With only UTC we'd lose the semantics meaning of local hours. Hence combining local hours and UTC in one clock face.
> We actually can't just use UTC as is and eliminate time zones completely. If we do so, people in some places would go to work at 2am, in other places at 8pm. That's even more confusing.
If we adopt hTime, people in some places would go to work at C:00, and in other places at U:00. What’s the difference, really? If you say that people in London think that 8-4 UTC (now 9-5 BST) are working hours and would be confused their NYC colleagues would say they are working 4-12 (now 9-5 EDT), then you get the same “confusion” if London thinks I-Q and NYC says N-V.
If we adopt hTime, people in some places would go to work at C:00, and in other places at U:00. What’s the difference, really? If you say that people in London think that 8-4 UTC (now 9-5 BST) are working hours and would be confused their NYC colleagues would say they are working 4-12 (now 9-5 EDT), then you get the same “confusion” if London thinks I-Q and NYC says N-V.
You're right :) The concept is to use both together. And that's what the clock is doing. It keeps local times, and adds UTC as a global time, then maps them together with location-offset-based rotating.
Have you thought about including an additional identifier for the day too? That might help in addressing the edge cases that fall on different days.
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.
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.
Fun fact: my local vaccination centre used Nepal time clock as the “minutes” part for a clock that was 15 minutes slow. Why?
That clock showed you the vaccination time that was now safe to leave, having been observed for 15 minutes.
That clock showed you the vaccination time that was now safe to leave, having been observed for 15 minutes.
That's an interesting use case! :)
Yep I appreciated the “geek” that hacked that up. I hope there was some humour behind it. The “normal” thing would be to get a wall clock and wind it back 15!
It's a little unfortunate that they keep the minute part numeric, since this has the same problem as displaying UTC times for India - India Standard Time has a 30-minute offset in addition to an hour offset, so "K:43" in hTime is "16:13" in Delhi.
Myanmar has a +30m delta too, as has Australian Central Time and Newfoundland.
As mentioned elsewhere Nepal has a +45m delta.
edit OK I crunched the numbers
Country / Pop. / Timezone
* Afghanistan 32.9M UTC+04:30
* Central Australia (Northern Territory and South Australia) 246.5k + 1.771M UTC+09:30
* India 1.353B UTC+05:30
* Iran 83.1M UTC+03:30
* Myanmar 55.6M UTC+06:30
* Nepal 28M UTC+05:45
* Newfoundland and Labrador 520k UTC-03:30
This comes out to around 1.556B people or around 20% of the world's population.
As mentioned elsewhere Nepal has a +45m delta.
edit OK I crunched the numbers
Country / Pop. / Timezone
* Afghanistan 32.9M UTC+04:30
* Central Australia (Northern Territory and South Australia) 246.5k + 1.771M UTC+09:30
* India 1.353B UTC+05:30
* Iran 83.1M UTC+03:30
* Myanmar 55.6M UTC+06:30
* Nepal 28M UTC+05:45
* Newfoundland and Labrador 520k UTC-03:30
This comes out to around 1.556B people or around 20% of the world's population.
You're right. Firstly, I don't really understand why those countries decided to go with a 30-minute offset. It's adding even more confusion to the whole time zone and daylight saving thing. hTime utilizes UTC, hence the 30 minutes difference. However, that's something to think more about and see how to fix it properly. Thanks for the feedback.
Would you give hTime a go and test it for some days? I'd love to hear more feedback.
Would you give hTime a go and test it for some days? I'd love to hear more feedback.
Nepal does a 45 minute offset because it's centered around a holy mountain: http://bossnepal.com/sacred-mountain-gauri-shankar/
This just shows you didn’t even do the basic background research before jumping head-first into this idea (not to mention blaming the countries). Why would someone try your app knowing full-well it is fundamentally broken?
I believe I did the research. It's written in a blog post I published about time zones and the clock's concept https://medium.com/adventures-in-consumer-technology/introdu.... That's what I'm trying to solve.
I appreciate your candor feedback. When users worldwide use the clock, they'll see both global and local times in one place, the global time will be "without" the minutes offset, and the local time will be "with" the minutes offset, so the mapping does actually work and I don't think it's broken in that sense. And as any project, there's always room for improvement.
I appreciate your candor feedback. When users worldwide use the clock, they'll see both global and local times in one place, the global time will be "without" the minutes offset, and the local time will be "with" the minutes offset, so the mapping does actually work and I don't think it's broken in that sense. And as any project, there's always room for improvement.
The mapping is clear, and I think many of us get it that anyone in any time zone can look at the mapped clock and see the same time.
As well, I personally think that building on UTC but making it clearly recognizable is a clever approach (avoiding, as you say; “Meet me at to 2PM UTC.” being quickly internalized in someone’s brain as 2PM local time), but there are too many (known) edge cases that this cannot solve (such as arbitrarily-numbered minute offsets, and possibility of confusing dates when setting the time)
As well, I personally think that building on UTC but making it clearly recognizable is a clever approach (avoiding, as you say; “Meet me at to 2PM UTC.” being quickly internalized in someone’s brain as 2PM local time), but there are too many (known) edge cases that this cannot solve (such as arbitrarily-numbered minute offsets, and possibility of confusing dates when setting the time)
Thanks for the clarification, makes sense.
When OP talked about it being broken, I suspect they meant something like “With enough knowledge of the complexities of international timezones, as well as the psychology internal to administrators and the public, it is clear that this specific approach cannot solve the problem for everyone world wide without an amount of amount of public shift that is borderline impossible. (For reference, see the XKCD comic about creating a unifying standard)”.
It's definitely challenging to influence people's behavior especially when it comes to something so essential like time and the clock. However, I believe dealing with time zones when working with distributed teams is actually more challenging. I can't count the times people missed a meeting or a deadline by an hour because they miscalculated time zones, hence the work on hTime.
I have to say, I don't understand what you mean by this.
When I view https://thehtime.com/location?name=Canada+-+St.+John%27s currently I see:
If I (in a timezone with an even number of hours offset) schedule a meeting at S:30, what time is someone from St John's going to show up? (I think half an hour late?)
When I view https://thehtime.com/location?name=Canada+-+St.+John%27s currently I see:
Time Locally: 14:52
Time worldwide: R:52
If I (in a timezone with an even number of hours offset) schedule a meeting at S:30, what time is someone from St John's going to show up? (I think half an hour late?)
What I mean is for example: India as you mentioned above in the list. On hTime https://thehtime.com/location?name=India+-+Mumbai the local time is with a 30-minute offset, and the global isn't following UTC.
For St. John's offset, I actually wasn't aware of it, from the data I have it seemed to me that Canada in general doesn't have that. But worry not, I just fixed it on the website and added it to the algorithm offsets, please check again and let met know what you think. Here is the link to St. John - Canada https://thehtime.com/location?name=Canada+-+St.+John%27s
If a meeting is scheduled using hTime, then it'll be in hTime with half an hour offset from the local hour in St. John.
For St. John's offset, I actually wasn't aware of it, from the data I have it seemed to me that Canada in general doesn't have that. But worry not, I just fixed it on the website and added it to the algorithm offsets, please check again and let met know what you think. Here is the link to St. John - Canada https://thehtime.com/location?name=Canada+-+St.+John%27s
If a meeting is scheduled using hTime, then it'll be in hTime with half an hour offset from the local hour in St. John.
Well, it works for my team, so I don't see a problem. Not everything needs to work for everybody in every circumstance to be helpful.
Can this be used for profiling on the internet? Ie. if someone's clock is 15 minutes before the standard they are residing in Nepal?
Yes it can and is used for profiling, but it's even easier than that - you can just call "Intl.DateTimeFormat().resolvedOptions().timeZone" on modern browsers or use Date's getTimezoneOffset
Reminds me of the time our firm scheduled a training session for cross-cultural awareness, at 1 a.m. local time, on a Saturday. I kid you not.
Your firm should use hTime then for scheduling :D They could use the "Meeting Time" https://thehtime.com/intersect feature to make sure it's a good time for everyone.
How is this any better than just using UTC written as 14:15Z?
It is a bit nice to hide the number that is not correct, but it makes the lookup a little harder than an offset too. Not to mention the worst part which is that hour hour goes by but there is no numerical increment to see.
It is a bit nice to hide the number that is not correct, but it makes the lookup a little harder than an offset too. Not to mention the worst part which is that hour hour goes by but there is no numerical increment to see.
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?
I can simply change the letters to numbers, do you think that'd help?
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.
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.
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.
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.
> 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.
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
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
> 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...
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.
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
True. I'm actually fine with that. Main thing is we find a good way to get rid of time zone math! :)
Reminds me of Swatch's "Internet Time" from the 90's - https://en.wikipedia.org/wiki/Swatch_Internet_Time
Also, obligatory XKCD: https://xkcd.com/927/
Also, obligatory XKCD: https://xkcd.com/927/
The issue with Internet Time is that it used a completely new approach of time. It's hard to know what 965 means in our local time. The idea here is to simply keep the 24 hours, 60 minutes, 60 seconds and add UTC to that making the clock showing both local and global times. And then rotate UTC according to the location which then unifies the reading of time everywhere. Something Internet Time didn't do.
I work in the UK for a company based out of Denver. I know that I need to subtract 7 hours from my time to figure out the local time there, and they need to do it in reverse. But with this H time I would have to subtract 7 letters from my time to understand what the relative local time in Denver is. Sure it's P:30 for both of us, but I don't know what P minus seven is to know if that's when noon is and they may or may not be at lunch.
I guess the idea is you'd have to know "Our Denver office hours are between H and W, and they have lunch at hour P.", so you don't schedule meetings at P:00.
But well, I don't think it really works. Add another timezone to the mix and you're going to get a jumble of letters you won't remember, you'll have to write it down, and at that point you might as well use a diagram like this: https://everytimezone.com (which I think can also be made analog, just add a few lines for "Lunchtime in London", "Lunchtime in Denver", etc.
But well, I don't think it really works. Add another timezone to the mix and you're going to get a jumble of letters you won't remember, you'll have to write it down, and at that point you might as well use a diagram like this: https://everytimezone.com (which I think can also be made analog, just add a few lines for "Lunchtime in London", "Lunchtime in Denver", etc.
Yes, I'm hearing this more now about the letters. It obviously seems that the letters make it harder to comprehend which I understand. Do you think replacing letters with numbers would help? Then you'd see both local and global (UTC) times in numbers, that would probably make it easier to use.
That could be solved with software that displayed the local time for each participant you add to an event. But then I guess I don't see the point of this any more.
True, but not for all events. For example, webinars or global events like SpaceX's launch or the Olympics games. If a game starts at 2pm Tokyo time, I have no direct clue what that could be in my local time. If the game starts at N:00, then I know in my mind what that is.
I suspect the only solid way to do this is to have the ntime clock visible to all office employees.
“Oh, it’s O:56, I better prep for the meeting at P:30”
“Oh, it’s O:56, I better prep for the meeting at P:30”
That'd work
The thing about the hour -- the part that's being abstracted away here -- is that (in most cases) it carries semantic meaning about daylight and thus about "waking-world" and circadian-rhythm expectations.
Yes, with timezones and UTC-offsets I have to keep in mind that 8:00 in my timezone might be 3:00 in someone else's timezone, but once I do the simple math of adding the offsets and doing any necessary modulos, I now know that the meeting time I've chosen almost certainly isn't a reasonable meeting time for that person.
I know from experience that for the overwhelming majority of people in the world, 3:00 is still probably sleeping time, regardless of what timezone that 3:00 is in. 3:00 in UTC is sleeping time in London, 3:00 in UTC-5 is sleeping time in Atlanta, 3:00 in UTC+9 is sleeping time in Tokyo -- in any case, 3:00 is sleeping time.
Attempts to have "one world timezone", even leaving out the existence of fractional-hour timezone offsets, will always throw away that semantic detail about human schedules.
For example, let's say you just enforce that everyone uses UTC. Congratulations, you no longer have to do offset math.
Except that you have no idea if 10:00 is a reasonable meeting time for anyone within a few timezones of you (which remember, no longer exist, so you can't really use them as references). You no longer have to memorize each participant's offsets, but now you have to memorize the daylight hours for each participant instead, and that's arguably harder (X's daylight hours are 8:00->16:00, but Y's daylight hours are 14:00->2:00, but then Z's daylight hours are 12:30->20:30).
Yes, there are companies with overseas contracts who dedicate some staff to working the same hours as their overseas counterparts. Do we really want that to become the global norm, though? Because if not, then "daylight hours" remains an important concept, and it's already baked semantically into the system of timezones we have today, more simply than the alternative.
So if we toss out the piece of information that conveys the detail about "daylight hours" (which is what this clock does with its letters-instead-of-hours), then we're losing that information, and making it much easier to trample all over somebody's reasonable working schedule.
Yes, with timezones and UTC-offsets I have to keep in mind that 8:00 in my timezone might be 3:00 in someone else's timezone, but once I do the simple math of adding the offsets and doing any necessary modulos, I now know that the meeting time I've chosen almost certainly isn't a reasonable meeting time for that person.
I know from experience that for the overwhelming majority of people in the world, 3:00 is still probably sleeping time, regardless of what timezone that 3:00 is in. 3:00 in UTC is sleeping time in London, 3:00 in UTC-5 is sleeping time in Atlanta, 3:00 in UTC+9 is sleeping time in Tokyo -- in any case, 3:00 is sleeping time.
Attempts to have "one world timezone", even leaving out the existence of fractional-hour timezone offsets, will always throw away that semantic detail about human schedules.
For example, let's say you just enforce that everyone uses UTC. Congratulations, you no longer have to do offset math.
Except that you have no idea if 10:00 is a reasonable meeting time for anyone within a few timezones of you (which remember, no longer exist, so you can't really use them as references). You no longer have to memorize each participant's offsets, but now you have to memorize the daylight hours for each participant instead, and that's arguably harder (X's daylight hours are 8:00->16:00, but Y's daylight hours are 14:00->2:00, but then Z's daylight hours are 12:30->20:30).
Yes, there are companies with overseas contracts who dedicate some staff to working the same hours as their overseas counterparts. Do we really want that to become the global norm, though? Because if not, then "daylight hours" remains an important concept, and it's already baked semantically into the system of timezones we have today, more simply than the alternative.
So if we toss out the piece of information that conveys the detail about "daylight hours" (which is what this clock does with its letters-instead-of-hours), then we're losing that information, and making it much easier to trample all over somebody's reasonable working schedule.
What's the obsession with knowing which daylight hour offset it would be for someone else? Wouldn't you rather know a range of hours that works for them rather than a range of hours you assume they'll be awake (and hopefully not busy)?
If the position of the sun is truly important to your use case then knowing a location is "UTC+9" as far as sunshine hours go is still able to tell you that without requiring you encode that information into the time value itself.
If the position of the sun is truly important to your use case then knowing a location is "UTC+9" as far as sunshine hours go is still able to tell you that without requiring you encode that information into the time value itself.
> What's the obsession with knowing which daylight hour offset it would be for someone else?
This is already answered in the post you are replying to, so I assume this is you demanding an external source:
https://www.wikiwand.com/en/Circadian_rhythm
https://www.wikiwand.com/en/Sleep
This is already answered in the post you are replying to, so I assume this is you demanding an external source:
https://www.wikiwand.com/en/Circadian_rhythm
https://www.wikiwand.com/en/Sleep
My inquiry was not about or asking for proof of the idea people sleep at night rather why that info is preferred over more salient information as seen by continuing to the following, unquoted, sentence.
I don't believe parent was "demanding" anything. Simply asking an increasingly relevant question as work moves from office to home and the remote work pool expands.
Thanks for the detailed explanation. But as nixpulvis said, the clock doesn't remove the local times and replace them with UTC. That's not the idea. The clock actually brings the best of both local times and UTC together in one clock. Local times are here to stay with UTC. What the clock is that it maps them together by rotating the UTC layer (in letters) so the reading of time is the same everywhere for everyone.
I hear you on waking time. For that I've build the "Meeting Time" feature that makes sure to find the best time for a meeting for different locations where it's a good time to meet for everyone. For example, the best time to have a meeting between San Francisco, New York, London, and Berlin is between P-R baring in mind that the clock makes sure that the meeting is between 8am and 19 (7pm) for everyone. And this is all configurable :) You can also share the link of the meeting time as this one https://thehtime.com/intersect?locations=USA+-+San+Francisco...
Happy to hear your thoughts on this feature.
I hear you on waking time. For that I've build the "Meeting Time" feature that makes sure to find the best time for a meeting for different locations where it's a good time to meet for everyone. For example, the best time to have a meeting between San Francisco, New York, London, and Berlin is between P-R baring in mind that the clock makes sure that the meeting is between 8am and 19 (7pm) for everyone. And this is all configurable :) You can also share the link of the meeting time as this one https://thehtime.com/intersect?locations=USA+-+San+Francisco...
Happy to hear your thoughts on this feature.
>The clock doesn't remove the local times and replace them with UTC
You're right, this clock doesn't remove the local times and replace them with UTC; instead this clock overlays the local times with a replacement "A-X time", which is a single timezone applied to everywhere. Not UTC, but a new, non-standardized "DIY" UTC. That's the whole thing it does: throw away the location-specific "daylight-hours" quantifier (the "hour" part of the time) and replace it with a "single timezone" version (where it's "F:30" everywhere on earth at the same time), but instead of the globally-recognized standard of UTC, it's a brand-new standard that arbitrarily uses letters rather than numbers (with an "origin point" that's unclear -- where in the world is A:00 equal to 00:00? I couldn't find it, so I couldn't easily figure out my timezone's offset so that I could reason about daylight hours).
I've seen clocks that do this already, but with UTC instead of "A-X time": they have two "dials", one for local time and one for UTC. That's all this is, just with letters instead of numeric hours (an arbitrary substitution) and a newly-made-up "base" timezone instead of UTC.
There's no functional difference between consulting a clock like this so that you can say "F:30" to all of your teammates and it'll be the same time everywhere, and consulting a UTC clock so that you can say "10:30 UTC" to all of your teammates and it'll be the same time everywhere, except that most people have memorized their local UTC offset and can go "oh, okay, 10:30 - 5 hours = 5:30", where with F:30 they have to go consult your website instead.
Having a configurable "meeting time" feature is neat, but like...that's an extra tool you had to build on top of your clock system, not an intrinsic feature of your clock system itself. I need a complex translator tool to tell me what A-X hours are reasonable for meeting with people because I can't just simply apply offsets in my head and get intuitive results (especially because the "base" offsets are unclear).
I think a lot of folks overestimate how painful it is to do modulo addition/subtraction, compared to how painful it is to learn an entirely new system of timekeeping-and-translation.
You're right, this clock doesn't remove the local times and replace them with UTC; instead this clock overlays the local times with a replacement "A-X time", which is a single timezone applied to everywhere. Not UTC, but a new, non-standardized "DIY" UTC. That's the whole thing it does: throw away the location-specific "daylight-hours" quantifier (the "hour" part of the time) and replace it with a "single timezone" version (where it's "F:30" everywhere on earth at the same time), but instead of the globally-recognized standard of UTC, it's a brand-new standard that arbitrarily uses letters rather than numbers (with an "origin point" that's unclear -- where in the world is A:00 equal to 00:00? I couldn't find it, so I couldn't easily figure out my timezone's offset so that I could reason about daylight hours).
I've seen clocks that do this already, but with UTC instead of "A-X time": they have two "dials", one for local time and one for UTC. That's all this is, just with letters instead of numeric hours (an arbitrary substitution) and a newly-made-up "base" timezone instead of UTC.
There's no functional difference between consulting a clock like this so that you can say "F:30" to all of your teammates and it'll be the same time everywhere, and consulting a UTC clock so that you can say "10:30 UTC" to all of your teammates and it'll be the same time everywhere, except that most people have memorized their local UTC offset and can go "oh, okay, 10:30 - 5 hours = 5:30", where with F:30 they have to go consult your website instead.
Having a configurable "meeting time" feature is neat, but like...that's an extra tool you had to build on top of your clock system, not an intrinsic feature of your clock system itself. I need a complex translator tool to tell me what A-X hours are reasonable for meeting with people because I can't just simply apply offsets in my head and get intuitive results (especially because the "base" offsets are unclear).
I think a lot of folks overestimate how painful it is to do modulo addition/subtraction, compared to how painful it is to learn an entirely new system of timekeeping-and-translation.
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.
Would love to hear your thoughts on the rotating UTC layer vs an extra UTC layer + hand.
We always used Zulu (GMT+0) to coordinate meetings around the globe, but this is a very nice approach to coordinate time differences. Daylight saving times are just way too chaotic around the globe, as every country does their own thing anyways.
One thing though: Different countries imply different work hours and laws/regulations.
For example, it is illegal to work more than 10 hours in Germany, so most companies stick to the 0800-1630 work time approach whereas the 30 minutes break is also required by law.
Something like this would be nice to represent in an overlap/border/chart(?) with colors for each location around the clock so that you can see where times could overlap if you e.g. come late in the office to start work.
One thing though: Different countries imply different work hours and laws/regulations.
For example, it is illegal to work more than 10 hours in Germany, so most companies stick to the 0800-1630 work time approach whereas the 30 minutes break is also required by law.
Something like this would be nice to represent in an overlap/border/chart(?) with colors for each location around the clock so that you can see where times could overlap if you e.g. come late in the office to start work.
Interesting. First time I hear about using Zulu for meetings. hTime is similar in a way, and as you mentioned aiming at making it more convenient by combining local and global (UTC) times together.
It's a good idea to do the working layers on top as well. did you check the "Working Availability" https://thehtime.com/range feature? There you can actually specify your working availability and share this with others globally using a link. this might help.
Would you like to give hTime a go to coordinate meetings instead of Zulu for some days? I'd love to hear more feedback from a daily usage by a team. That'd be really helpful.
It's a good idea to do the working layers on top as well. did you check the "Working Availability" https://thehtime.com/range feature? There you can actually specify your working availability and share this with others globally using a link. this might help.
Would you like to give hTime a go to coordinate meetings instead of Zulu for some days? I'd love to hear more feedback from a daily usage by a team. That'd be really helpful.
That would be depressing. If I’m away from work overnight I want to get the work done. I’d rather babysit a system for 15 hours a day for 3 days then go home and have a colleague do it for the next 3, rather than have to do 6 days with both of us on site.
> That would be depressing. If I’m away from hoke overnight I want to get he worked done. I’d rather babysit a system for 15 hours a day for 3 days then go home and have a colleague do it for the next 3, rather than have to do 6 days with both of us on site.
Honestly I don't understand your comment!?
Why do you have to babysit the system? My suggestion was an extension to the existing clock app that OP made. Nothing prevents OP from making settings storable via localStorage, so I don't know where your assumptions come from?
Honestly I don't understand your comment!?
Why do you have to babysit the system? My suggestion was an extension to the existing clock app that OP made. Nothing prevents OP from making settings storable via localStorage, so I don't know where your assumptions come from?
Sorry posting from a phone which has terrible autocorrect and hadn’t edited.
In repose to “illegal to work more than 10 hours in Germany”
I had a call last night to go to a field in the middle of nowhere for 3 days to look after an event as the colleague who was supposed to do it has covid.
This means sitting on site doing whatever I want, until/unless something goes wrong.
The coverage needed is 12 hours a day, so that’s fine, I do the job, get paid the overtime, and another colleague takes over on Saturday to do the same job for a few days.
If I was limited to 10 hour days I couldn’t cover 12 hours, we’d need two people on site, and that means I’d have to be away from home twice as long.
That’s not a good thing for me
In repose to “illegal to work more than 10 hours in Germany”
I had a call last night to go to a field in the middle of nowhere for 3 days to look after an event as the colleague who was supposed to do it has covid.
This means sitting on site doing whatever I want, until/unless something goes wrong.
The coverage needed is 12 hours a day, so that’s fine, I do the job, get paid the overtime, and another colleague takes over on Saturday to do the same job for a few days.
If I was limited to 10 hour days I couldn’t cover 12 hours, we’d need two people on site, and that means I’d have to be away from home twice as long.
That’s not a good thing for me
The regulation in Germany for the 10 hours hard limit is actually quite important, as it's implemented via the Arbeitszeitgesetz (ArbZG) [1].
If you have an accident and it turns out you worked more than 10 hours that day, social insurance won't cover it and you're basically broke for the rest of your life if it was an accident with say, a hospital stay and an emergency operation.
Also the 10 hours max are only possible if on average within the surrounding 24 weeks (6 months) you work less than 8 hours. If it's more than that, you're also not covered by insurance.
My point was originally just pointing to this example that 12 hour or longer shifts aren't possible in some countries due to endangering the social insurance there dependent on local laws.
The addition I suggested had in mind that you could see "which shift" is working there from when to when so that it's easier to coordinate in such scenarios.
[1] https://www.gesetze-im-internet.de/arbzg/BJNR117100994.html
If you have an accident and it turns out you worked more than 10 hours that day, social insurance won't cover it and you're basically broke for the rest of your life if it was an accident with say, a hospital stay and an emergency operation.
Also the 10 hours max are only possible if on average within the surrounding 24 weeks (6 months) you work less than 8 hours. If it's more than that, you're also not covered by insurance.
My point was originally just pointing to this example that 12 hour or longer shifts aren't possible in some countries due to endangering the social insurance there dependent on local laws.
The addition I suggested had in mind that you could see "which shift" is working there from when to when so that it's easier to coordinate in such scenarios.
[1] https://www.gesetze-im-internet.de/arbzg/BJNR117100994.html
> social insurance won't cover it
I don't think that's true, although you hear it often. It's true that accidents due to exhaustion can be a problem, but only if they can prove that your exhaustion was not work-related or that you refused offered alternatives, then the automatic accident coverage doesn't apply.
I don't think that's true, although you hear it often. It's true that accidents due to exhaustion can be a problem, but only if they can prove that your exhaustion was not work-related or that you refused offered alternatives, then the automatic accident coverage doesn't apply.
In Germany we would put three people on the job for 8 hours each. Working more than 8 hours is already the exception, 10 is the hard maximum (except for some exceptions like caring for people or management).
Germany still has a lot of blue-collar jobs, where limiting work time really cuts down on accident rates. Of course any law will catch some innocent cases in the cross-fire.
Germany still has a lot of blue-collar jobs, where limiting work time really cuts down on accident rates. Of course any law will catch some innocent cases in the cross-fire.
Germany is not some magical place where people never work more than 10h. That part of the law you quoted is only about regular shifts, whereas OP's example of being on site and basically waiting until something happens would very much fall under § 7.4, as being on standby, also it doesn't sound like this happens every week.
Yes, in general I won't complain, certainly not about those restrictions - but it's simply wrong to act as if no one had exceptional longer shifts, or what the OP did would be illegal.
Yes, in general I won't complain, certainly not about those restrictions - but it's simply wrong to act as if no one had exceptional longer shifts, or what the OP did would be illegal.
So 3 people
How about if I’m somewhere worse than Norfolk (where I am now). Say I have a certain amount of work to do in Gaza - say 180 hours of it. Do I send 3 people to do the job in 4 or 5 days, or do I keep them there twice as long or send twice as many people - doubling the length and footprint in country, massively increasing the risk (as well as more people being away from home for longer).
As the employee I would not be looking forward to spending a full evening in the Al Deira every night, assuming their generator is working. I’d rather spend time at home.
How does it even work with travel - I’ve spent 6 hours getting through customs and immigration in some places, let alone the flight to get there.
How about if I’m somewhere worse than Norfolk (where I am now). Say I have a certain amount of work to do in Gaza - say 180 hours of it. Do I send 3 people to do the job in 4 or 5 days, or do I keep them there twice as long or send twice as many people - doubling the length and footprint in country, massively increasing the risk (as well as more people being away from home for longer).
As the employee I would not be looking forward to spending a full evening in the Al Deira every night, assuming their generator is working. I’d rather spend time at home.
How does it even work with travel - I’ve spent 6 hours getting through customs and immigration in some places, let alone the flight to get there.
Travel time is (as you probably guessed) somewhat more complicated. The short version is that travel can happen outside your work time, as long as either immediately before or after the travel you aren't working (so e.g. you can travel from home to a customer outside work time, but traveling from work to a customer is work time).
As for traveling to Gaza: I guess you need more people or longer. The main concern of the law aren't the exceptional once-in-a-blue-moon cases but the everyday problem of workers. A better, safer work environment for millions is worth having some hypothetical people in Gaza for a bit longer.
As for traveling to Gaza: I guess you need more people or longer. The main concern of the law aren't the exceptional once-in-a-blue-moon cases but the everyday problem of workers. A better, safer work environment for millions is worth having some hypothetical people in Gaza for a bit longer.
OP, make sure to test your site with a non-maximized desktop browser that is taller than it is wide. Your site has severe layout issues in this orientation, with text overlapping text, the clock overlapping the text, the links overlapping the logo. It seems like it isn't using the mobile layout, it's trying to show the landscape desktop layout despite the portrait aspect of the browser window. On a mobile device it looks fine when it kicks into the mobile layout.
Great feedback. Noted and I'll work on fixing it.
In the bottom right it says "patent pending", does this mean you'll request payments for anyone using this in their own product? If so, it'll have no way of surviving when there are standarized, free datetime implementations/theories to use.
Not for using the clock no, charging people for reading time would be ridiculous :) The clock is only the first step to simplify time zone thinking. If people like to use this, I do have plenty of ideas on what to build on top of this.
> Not for using the clock no, charging people for reading time would be ridiculous
Agree, what about the other tools on the website, that is using the new time format you've created, are they within the patent too? It's really unclear what the patent is covering, and unfortunately your comment didn't help.
Agree, what about the other tools on the website, that is using the new time format you've created, are they within the patent too? It's really unclear what the patent is covering, and unfortunately your comment didn't help.
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.
Yes, I'm working with multiple organizations that are suffering from the problem it aims to solve, but the vagueness of the patent and lack of transparency would make it very hard to even start talking about it.
Common practice would be to have I and O excluded from use since they're commonly confused (I/J/1/l and O/Q/0.)
(And as other comments have noted, this breaks down in utility with 15/30min TZ offsets as well as when crossing the date line.)
(And as other comments have noted, this breaks down in utility with 15/30min TZ offsets as well as when crossing the date line.)
One issue with your graphical clock being modulus-24 is that it interferes with everyone's lifetime exposure to analog clocks that are modulus-12. Losing that spatial awareness of where the hour hand "typically" sits makes it harder to read.
I think simple text list of different locations and their current local time is much easier to mentally parse.
I think simple text list of different locations and their current local time is much easier to mentally parse.
24 hour clock faces are not completely novel idea, they have been around for a long time already. Never particularly popular, they have been used more in some niches. Soviets in particular seemed to be fond of them, you can find many Raketas etc with 24h faces.
Random modern example of 24h watch
https://www.oris.ch/en/watch/blue-eagles-limited-edition/01-...
Random modern example of 24h watch
https://www.oris.ch/en/watch/blue-eagles-limited-edition/01-...
I hear you. The awareness of the where the hand stands still works for local hours though. When working across-time-zones and scheduling client meetings, the list of local clocks and emails to coordinate become a hassle quickly in my experience.
>The awareness of the where the hand stands still works for local hours though.
It doesn't work for local because there's a fundamental difference of geometry between 12 vs 24 subdivisions of a 360 degree circle.
Look at the screenshot to see that the hour-hand pointing to "8" are different angles (240 degrees vs 300 degrees):
https://imgur.com/a/8DZCeqe
In your clock, it "looks like 10am" instead of 8am because of the accumulated lifetime repetition of reading traditional 12-hour clocks.
It doesn't work for local because there's a fundamental difference of geometry between 12 vs 24 subdivisions of a 360 degree circle.
Look at the screenshot to see that the hour-hand pointing to "8" are different angles (240 degrees vs 300 degrees):
https://imgur.com/a/8DZCeqe
In your clock, it "looks like 10am" instead of 8am because of the accumulated lifetime repetition of reading traditional 12-hour clocks.
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.
Honest q I hope doesn't sound rude: how is this different from @beat swatch time?
Looks really nice and I hope you and your process success, you're fixing a problem
Looks really nice and I hope you and your process success, you're fixing a problem
Not at all, thanks for asking and the nice wishes ;)
The Internet Time, Beats, is a completely new time/clock system. It’s unclear what 964 for example means. With this clock, I’m using the same time/clock system we all know well: 24 hours, 60 minutes, 60 seconds. The addition to that is UTC. Why? To make the clock show the global time as well, and then map the local time with the global time together in one clock face. By this, we can always be in sync locally and globally. The UTC layer in the middle is represented by letters to simply distinguish global from local times. This layer rotates with users according to their location on Earth. Why? To unify the reading of time when doing the mapping, so the reading of time is always the same no matter where users are. I understand that the letters might be confusing a bit, but this can be fixed easily by replacing them with numbers again.
Here is an example: 2 days ago there was the Apple event. It was at 10am PDT. I’m not sure what that is in my local time and other local times. If that event would be translated to hTime, it would be at R:00. No matter where we are, we can see the local and global hours for R:00, so no time zone calculations are needed any more.
I believe the barrier-to-entry with a 24-hour, 60-minute, 60-second system is simpler than Beat.
I believe the barrier-to-entry with a 24-hour, 60-minute, 60-second system is simpler than Beat.
@beat was a full decimalization of time (1000 'beats' per day).
This is just giving new, universal names to hours. I can see this working a lot better than the alternative (use GMT/UTC everywhere) as you'd always have mental contention as to whether you meant a time in local or GMT. This way you don't need the additional label. And I could imagine getting used to the idea that my workday lasted from P-X & the other geographical zones had their common hour blocs.
Potential issues:
* 0/O ambiguity
* presumably the day flips over when the hour goes from X->A, which means sometimes it's tomorrow already.
This is just giving new, universal names to hours. I can see this working a lot better than the alternative (use GMT/UTC everywhere) as you'd always have mental contention as to whether you meant a time in local or GMT. This way you don't need the additional label. And I could imagine getting used to the idea that my workday lasted from P-X & the other geographical zones had their common hour blocs.
Potential issues:
* 0/O ambiguity
* presumably the day flips over when the hour goes from X->A, which means sometimes it's tomorrow already.
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
I like the idea but for the teams I have worked with, the trouble they have with timing isn't going to be solved by any clock!
I'd love to hear more about that. What is the trouble? Maybe I can work on a solution to help.
The concept is interesting and creative but I also think it's just repackaging the problem it's trying to address but using a different element as the datum. This adds an additional step where you have to translate N:45 time to local by remembering how the letters are re-arranged for your specific area. Therefore, I don't think this solution really solves the original/intended problem it's trying to address but rather hides it behind the letters.
I'd suggest a good alternative is to just stick with Google Calendar/Microsoft Outlook and/or WorldTimeBuddy.
I'd suggest a good alternative is to just stick with Google Calendar/Microsoft Outlook and/or WorldTimeBuddy.
Skip I and O on the letters, and go up to Z. Then the letter component will not be mistaken for a numeric digit.
Done! Thanks for the feedback!
This makes sense, I've received this feedback several times today.
Would you like to give hTime a go and test it for some days? I'd love to hear some more feedback.
This page (https://www.smithsonianmag.com/smithsonian-institution/sandf...) has a picture of a mechanical pocket watch from the 1880s belonging to Sandford Fleming with the letters shown against each hour.
Cool, Thanks for sharing. I didn't know about Fleming's watch. The problem he was trying to solve back then is represented again today by distributed and remote work. Companies and teams have employees, customers, and parterres all over the world, and the 3-letter time zone system started to be more confusing, especially with daylight saving. UTC is a universal time, but unfortunately it's rare to see it used on a daily basis. The introduction of hTime is to simply bring UTC back as the central time globally and make it easier to use by combining it with local times. So we've got local and global times in one clock.
No J or V, Interesting those were sacrificed.
Probably for the same reasons mentioned here: https://news.ycombinator.com/item?id=28929226
They're easily confused with I and U, respectively.
They're easily confused with I and U, respectively.
Good feedback, probably I should be doing the same on hTime as well. I'll test more and see what's best for UX.
Maybe he just didn’t like the look of them, and wanted the day to end at Z.
You never know when a standard is based on a single person’s subjective choice. I think it’s fascinating personally.
You never know when a standard is based on a single person’s subjective choice. I think it’s fascinating personally.
Cool concept! The thing that I like about using A-X is that it helps avoid accidentally confusing "10" between local and UTC. IE, the longer I would use this, the more I get used to knowing that 8:00 is N:00 in my local time.
IMO: Something in the html needs cleanup. Depending on my window size, elements are always overlapping. (I'm on Chrome on Windows, with uBlock.)
IMO: Something in the html needs cleanup. Depending on my window size, elements are always overlapping. (I'm on Chrome on Windows, with uBlock.)
Great feedback! Yes, that's exactly the concept of letters and numbers for local and global times :) I'll work more on the responsiveness of the interface. There is something to improve every day.
Do you work across time zones? If yes, would you like to give hTime a go and test it for some days? I'd love to hear more feedback from daily usage of the clock.
Do you work across time zones? If yes, would you like to give hTime a go and test it for some days? I'd love to hear more feedback from daily usage of the clock.
Not anymore. Within a few hours, it's easy to accommodate in my head. But, spanning continents, it's a lot harder. I'm generally in the habit of always saying the time zone when talking across timezones.
BTW: Have you ever written a Fitbit watchface? They're pretty easy.
BTW: Have you ever written a Fitbit watchface? They're pretty easy.
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!
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!
We need human time: two dimensional time zones around major metropolitan areas, where time skews automatically a few minutes every morning at 3 a.m. to ensure that sunrise is the same time each day. No daylight savings jumps, and computers can handle cross-zone scheduling. This is easy to do now that everyone has a smart phone or smart watch.
While we’re at it, can we base weeks and months on the lunar cycle so that we have 13 months of exactly 4 weeks each?
Edit: Not sarcasm or a bit. Genuinely. I’d love to be more in sync with nature by having our time reference based on sunrise and the lunar cycles
Edit: Not sarcasm or a bit. Genuinely. I’d love to be more in sync with nature by having our time reference based on sunrise and the lunar cycles
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.
Thanks for the link, I just read it. Like hTime, there are some potential psychological show-stoppers but I feel like there’s a solid focus on using the very things that time were supposed to be based on.
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.
I use four suits of 13 weeks/cards, tied to local climate. Winter goes up from A of clubs to K, spring goes down from K of spades to A. A kind of a agricultural calendar.
You know when to plant things in the garden, when the peaks of trimming and gardening work are in the year, and when the heatwaves will be over with. It's very nice.
You know when to plant things in the garden, when the peaks of trimming and gardening work are in the year, and when the heatwaves will be over with. It's very nice.
That’s neat!
I like the explanation! I believe the 2 dimensional time zones are: local time zone, and global time zone. The local time zones already exist, the global time zone also already exists and it's UTC. hTime puts both in one clock so the reading of time is the same everywhere and still maps this to our local times for our daily life locally.
How would you implement your idea? Do you have any sketches or notes about that?
How would you implement your idea? Do you have any sketches or notes about that?
A tool that has been most useful for me when I am scheduling meetings cross-timezone:
http://timesched.pocoo.org/
IMHO when scheduling, you need to actually understand local time for all your attendees, so you can factor in things like when they are awake/asleep, when they might be driving to work, picking up their kids, etc.
But when simply reading/grokking times — i.e. in internal documents or web pages shared across timezones — I usually just want to see the timestamp expressed as my local time.
(Browser extension idea: automatically convert all dates/times to my local time, and be able to set rules for common timezone conversions for certain URLs/domains.)
IMHO when scheduling, you need to actually understand local time for all your attendees, so you can factor in things like when they are awake/asleep, when they might be driving to work, picking up their kids, etc.
But when simply reading/grokking times — i.e. in internal documents or web pages shared across timezones — I usually just want to see the timestamp expressed as my local time.
(Browser extension idea: automatically convert all dates/times to my local time, and be able to set rules for common timezone conversions for certain URLs/domains.)
Great feedback. I agree on the point of understating the local times of your attendees. hTime does that as well in the "Meeting Time" feature https://thehtime.com/intersect. Here you can choose the working-hour availability for all attendees so you make sure it's not after 10pm their time for example. You can then copy the link and share.
Here is an example of the best meeting time for a meeting taking place San Francisco, New York, London, and Berlin. In green, the clock shows the best time is between P-R baring in mind that the available time to meet is between 8 and 19 (7pm). Does that help?
Here is an example of the best meeting time for a meeting taking place San Francisco, New York, London, and Berlin. In green, the clock shows the best time is between P-R baring in mind that the available time to meet is between 8 and 19 (7pm). Does that help?
UI feedback: when selecting time zones to coordinate for a meeting, having a huge list to select from is such a pain that I would use some other tool just for that reason. Some of the common zones for an English-language tool are way at the bottom (USA, UK), and the USA ones aren't alphabetized. Also, there's no consistency with the naming: some are US states, others are cities, and I couldn't find some major cities, like San Francisco.
Just a list of time zones would be a lot easier. And even easier would be a world map that I can click on that would highlight the selected zones.
Just a list of time zones would be a lot easier. And even easier would be a world map that I can click on that would highlight the selected zones.
Thanks for the feedback! As for the list of cities, I'll work on simplifying that somehow. The map idea is pretty cool, it'll take a bit longer to implement. I'll be working on that soon.
San Francisco definitely exists in the list, I'm not sure why it doesn't show up on your side. Here is an example https://thehtime.com/intersect?locations=USA+-+San+Francisco...
Please let me know if it works.
San Francisco definitely exists in the list, I'm not sure why it doesn't show up on your side. Here is an example https://thehtime.com/intersect?locations=USA+-+San+Francisco...
Please let me know if it works.
I’m pretty sure that having “Accept and close” or “contact us to manage your cookie settings” as the only cookie options isn’t compliant.
It’s also an annoying dark pattern.
It’s also an annoying dark pattern.
I like this. It's probably a lot easier to adopt than my version which is basically a full day split into 10 parts (basically French Revolutionary Time) but the same across the whole world, and the clock face rotates so that local solar midday is always at the top of the clock. https://kybernetikos.github.io/UIT/
Thanks for the feedback. The main concept is to keep using 24 hours, 60 minutes, 60 seconds system and build the clock on top of that. Cool clock you have there as well.
I like that you use letters to make it clear which time is being discussed, cool idea and important - the problem with organising cross timezone isn't so much the complication of organising across timezone (you can look up a conversion online instantly and easily), it's more the ambiguity about which time any particular time being mentioned is.
I didn't originally create a new week for my system, but knowing which day a meeting is on is important too for meetings that are a long away apart. That's why I created nullday, unday, duoday, triday, quadday, pentday, hexday, heptday, and nonday.
I didn't originally create a new week for my system, but knowing which day a meeting is on is important too for meetings that are a long away apart. That's why I created nullday, unday, duoday, triday, quadday, pentday, hexday, heptday, and nonday.
yes, that's the concept behind the letters. Cool day names btw!
https://unixtimestamp.com When stating an offset time the most significant digits that are the same as now could be assumed, and not communicated. Also, for the least significant digits times with no seconds drop one zero; 5 minute intervals drop two zeros. So, a meeting tomorrow at 4 pm assuming EDT is at 8464.
A naive approach.
Time zones is not that simple. Many timezones have 15, 30, or 45 minutes offset (additional to the hour).
If I get time and date in UTC, I know when the meeting is supposed to start. If the time is 12:45 UTC and the meeting is at 16:00 I quickly know that the meeting starts in 3 hours and 15 minutes. Not that easy with M:45 and P:45
I do not like this.
If I get time and date in UTC, I know when the meeting is supposed to start. If the time is 12:45 UTC and the meeting is at 16:00 I quickly know that the meeting starts in 3 hours and 15 minutes. Not that easy with M:45 and P:45
I do not like this.
Nice feedback. Probably the letters make it harder to follow. I'll find a solution for that. I agree with you on knowing how to translate UTC to your time quickly, but one of the situations teams get into is: what is the best time to meet between San Francisco, New York, London, and Berlin for example? Here just thinking of UTC won't help unfortunately. hTime solves that as well. Another issue is the time zone names. For example, Apple's event was 2 days ago at 10am PDT, what is that to UTC, and then what's that in my local time? hTime is also trying to solve that by saying the event will take place at R:00, and done.
[deleted]
Newfoundland is 30 mins different.
Really this is just an offset in letters. Make the offset in numbers. I love the inner clock face idea.
Really this is just an offset in letters. Make the offset in numbers. I love the inner clock face idea.
Great feedback! I'm considering that as well, to try the inner clock with numbers. The main idea of letters is to help distinguishing global time (UTC) from local time. So let's meet at 11:00 is local, and let's meet at M:00 is global.
I'll try the numbers and test what would be simpler to use for users. Thanks!
I just fixed the 30-min offset for Newfoundland, here is the fixed time https://thehtime.com/location?name=Canada+-+St.+John%27s
Great! I’m delighted that you’re exploring other ways to describe time zones and offsets given how complicated it all is.
We gotta start somewhere and improve on the go :)
It's already broken idea. What good is a global time system that can't even know what day they're talking about. Monday Q:45?
One location can say Q:45 that matches another's Q:45 but if they're talking about a Q:45 several days out I can see people missing connections by 24h.
I'll stick with UTC date+time.
One location can say Q:45 that matches another's Q:45 but if they're talking about a Q:45 several days out I can see people missing connections by 24h.
I'll stick with UTC date+time.
Nice feedback! Well UTC date + time is the same here. It's then date + hTime ;) The need to add date is there anyway.
The problem with date + hTime is that it doesn't have a well defined midnight. Where each 'actual timezone' crosses into the next hTime day is at a different hTime letter. How confusing!
I wrote a console based tool based on a similar idea, it shows city-based timezones: https://zeitzono.org/
Unlike hTime, Zeitzono (currently) doesn't offer any meeting suggestion times, it's up to you to figure out when to schedule. That problem turned out to be kinda hard when more than a few cities are taken into consideration, so I never really added it in. (You do get to shift the clock to find the best time though.)
All in all a nice tool. My only suggestion would be maybe to add some more cities to search. I couldn't find some that I tried. Otherwise people have to mentally shift to the closet big city/state (e.g. Gainesville, FL, US -> Orlando/Tampa/Jacksonville), which may be a problem if you are not familiar with the area.
Also, it may be nice to add some aliases (eg. Bombay for Mumbai), because some places still go by their older names and not everyone has switched to the newer official name.
Unlike hTime, Zeitzono (currently) doesn't offer any meeting suggestion times, it's up to you to figure out when to schedule. That problem turned out to be kinda hard when more than a few cities are taken into consideration, so I never really added it in. (You do get to shift the clock to find the best time though.)
All in all a nice tool. My only suggestion would be maybe to add some more cities to search. I couldn't find some that I tried. Otherwise people have to mentally shift to the closet big city/state (e.g. Gainesville, FL, US -> Orlando/Tampa/Jacksonville), which may be a problem if you are not familiar with the area.
Also, it may be nice to add some aliases (eg. Bombay for Mumbai), because some places still go by their older names and not everyone has switched to the newer official name.
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.
GeoNames (http://www.geonames.org/) offers a downloadable database of cities with more than 15k population and their time zones. They list aliases as well. That's what Zeitzono uses. Just use that.
(You don't have to use all the listed cities if it slows down the hTime web app, just pick some minimum population threshhold (eg. every city larger than 100k people) and use those.)
(You don't have to use all the listed cities if it slows down the hTime web app, just pick some minimum population threshhold (eg. every city larger than 100k people) and use those.)
We need a standard for serializing both time and place in order to specify local time. It is already done ad-hoc using "continent/city" timezone database. Current three-letter timezones have the disadvantage that a place can change a timezone.
Timezones can change when specified by continent/city too. The bigger problem with three-letter zone names is that they're not unique. I found 3 different definitions of CST for example.
another problem with the 3-letter system is that it's not always 3 letters. With daylight saving CST become CEST which is then +-1 different depending where you are.
With hTime and bringing UTC into the clock, I'm aiming at eliminating the need to think of the 3-letter system altogether. If I know what time globally is (UTC) and what it means in my local time, then I won't need to know what CET or PT is anymore. hTime gets the job done using "one clock". The idea of UTC here is that it's a rotating UTC. So hTime utilizes where you are on Earth and uses that to rotate UTC accordingly so you get the same reading of time everywhere. That's a global time concept, which what UTC is about.
In the U.S. CST becomes CDT in the summer. Which country changes it to CEST?
ah sorry, that's CET (not CST) to CEST. That's Europe Central Time to Europe Central Summer Time. I believe we better off using UTC only.
I think computers may be better off using UTC, but people are still better off with local time. I'd hate to be at UTC+11 or UTC-11 and have the date change in the middle of the day.
When timezone for a city changes and you store time with timezone name/offset, you won't know. If you store time with location, you are one update of tzdata away from automatically solving the problem.
Except that tzdata doesn't store offset rules for every city. You still need to know which city represents your location, which is just as arbitrary as some random timezone code. Every once in a while zone boundaries or local zone rules change, so what was once your reference city is obsolete.
Sure, not in tzdata, but data as which county is under which timezone certainly must exist somewhere. All I ask to people whom it concerns to sit down and thoughtfully agree how to process location-based local time.
Yes storing time like "2021-11-01 10:00 Europe/Warsaw/Łękołody/Chrząszczyrzewoszyce/" souds absurd...but such absurdities have the uncanny tendency to come true and it's good if someone preemptively tries to clear things up.
Yes storing time like "2021-11-01 10:00 Europe/Warsaw/Łękołody/Chrząszczyrzewoszyce/" souds absurd...but such absurdities have the uncanny tendency to come true and it's good if someone preemptively tries to clear things up.
This is a classic example of a product that's not been thought through. half-hour and 45min timezones are ignored (and plain wrong when selected on the website). Not to mention it's not very practical as the clock is hard to read.
I live in the US. Most companies and organizations here use 12 hour time, so I use it too. The work hour selection is using 24 hour time. It would be a nice UX improvement to present the time using the user's current locale settings.
It is all of our duty when working in/with America/ns to use 24h time as often as possible. Same goes for metric.
Americans call it "military time" because the US military uses it. I like to remind people that the entire rest of the world uses it, too, and that 12h time should just be called "American civilian time".
Americans call it "military time" because the US military uses it. I like to remind people that the entire rest of the world uses it, too, and that 12h time should just be called "American civilian time".
It is all of our duty when working in/with America/ns to use 24h time as often as possible.
It is all of our duties to learn about, respect, and embrace cultures that are different from our own.
Just as I'm not going to take a job in France and tell the bakery how to make baguettes, I don't expect someone from France to come to the United States and be critical of the clock on the wall.
The technosphere is too often all about making the world standardized, bureaucratic, and homogenized. In other words: boring. I'd rather live in a world with many different cultures that I can learn about and explore. Who cares if it doesn't fit neatly into something that works for a computer? They're supposed to work for us, not the other way around.
It is all of our duties to learn about, respect, and embrace cultures that are different from our own.
Just as I'm not going to take a job in France and tell the bakery how to make baguettes, I don't expect someone from France to come to the United States and be critical of the clock on the wall.
The technosphere is too often all about making the world standardized, bureaucratic, and homogenized. In other words: boring. I'd rather live in a world with many different cultures that I can learn about and explore. Who cares if it doesn't fit neatly into something that works for a computer? They're supposed to work for us, not the other way around.
I like to remind people that the entire rest of the world uses it
So the United Kingdom, the Republic of Ireland, most of Canada, Australia, New Zealand, India, Pakistan, Bangladesh, Malaysia, Malta, Egypt, Mexico, Nepal, and the Philippines aren't part of the world.
https://en.wikipedia.org/wiki/12-hour_clock
So the United Kingdom, the Republic of Ireland, most of Canada, Australia, New Zealand, India, Pakistan, Bangladesh, Malaysia, Malta, Egypt, Mexico, Nepal, and the Philippines aren't part of the world.
https://en.wikipedia.org/wiki/12-hour_clock
https://en.m.wikipedia.org/wiki/Date_and_time_notation_in_th...
> Both the 24-hour and 12-hour notations are used in the United Kingdom
> The 24-hour notation is used in timetables and on most digital clocks, but 12-hour notation is still widely used in ordinary life. The 24-hour notation is used more often than in North America – transport timetables use it exclusively, as do most legal documents – but not as commonly as in much of the non-English-speaking world.
> Both the 24-hour and 12-hour notations are used in the United Kingdom
> The 24-hour notation is used in timetables and on most digital clocks, but 12-hour notation is still widely used in ordinary life. The 24-hour notation is used more often than in North America – transport timetables use it exclusively, as do most legal documents – but not as commonly as in much of the non-English-speaking world.
[deleted]
This isn’t correct. I’ve lived in UK, Australia, and Japan and all those places use 12 hour time.
Although in the UK at least, railways universally use the 24-hour clock, thereby regularly exposing a larger fraction of the population to it (in Australia a quick search seems to indicate that only NSW uses 24 hour time for its timetables?).
Great feedback! I'll add this as an option, so users can use either 24h or 12h. Thanks!
"Palestine/Jerusalem" is a very, eh, historical spelling.
Here we go again.
https://qntm.org/abolish
https://qntm.org/calendar
https://qntm.org/abolish
https://qntm.org/calendar
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.
Tom Scott's rant on time-zones is as relevant as always
https://www.youtube.com/watch?v=-5wpm-gesOY
https://www.youtube.com/watch?v=-5wpm-gesOY
yup, always
I do appreciate the functionality and goal of the app, but it's quite confusing for me. There are many tabs you can use, and it will probably need quite a bit of a learning curve.
Thanks for the feedback! What are the confusing part except for the tabs? I'd love to work on that and improve it.
I like the idea of galactic/orbital time, to coordinate between planets
You just opened up Pandora's Box though... there are so many corner cases
You just opened up Pandora's Box though... there are so many corner cases
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.
It would be really useful if anyone could build a Circadian Clock that works for every country/region.
How would that work, can you elaborate more please?
Perhaps my phrasing was incorrect.
Let's say I choose a country, United States, and then I'll be able to see a 24-hour clock showing Circadian Rhythms.
Perhaps, using precise location via ip address is better.
Let's say I choose a country, United States, and then I'll be able to see a 24-hour clock showing Circadian Rhythms.
Perhaps, using precise location via ip address is better.
It is weird to me to see 24 on a watch face. I know some countries use it but I for me after 23:59 comes 00:00 not 24:00.
I love this - great idea!
Portrait mode on chrome / desktop is broken pretty badly.
Patent pending - what does this mean?
Portrait mode on chrome / desktop is broken pretty badly.
Patent pending - what does this mean?
Thanks! Yes I got the feedback on the responsiveness. I'll work on fixing thats.
This clock smells like Esperanto.
I believe I'd prefer the remainder of dividing Unix time by seconds in a day.
That also works, but unfortunately not for everyone working remotely and need to schedule meetings, webinars, online conferences, define product deadlines, etc. I'm hoping that hTime is going to simplify all of that by brining UTC back to our everyday life.
Things like Calendly make this a non issue.
This is why people make fun of tech bros
Why is Jerusalem under Palestine?
i have no idea what's going on.
[deleted]
I create a meeting Friday at B:00.
Is that Thursday or Friday in Sydney? In anchorage?
T:00 on Thursday would be in about 7 hours from now for someone in Auckland, but in 31 hours for someone in San Francisco.
What about a meeting that occurs at 10am local time in New York every day? What happens when the clock changes. The reason to schedule meetings to a timezone is to account for clock changes, otherwise we could just use UTC and be far less confusing that’s this.