I'm building a new clock to eliminate time zone calculations, a clock that demolishes the need for time zones.
Why? To simplify scheduling & communicating time when working globally. So no PDT, PT, CET, nor UTC +2 -7. UTC is already the universal time, but almost nobody is using it on a daily basis.
The clock I'm building brings UTC back in a new way, a UTC integrated into the clock and rotates with you according to your location on Earth. The clock knows where you are on the globe and adjusts itself for you. This unifies the reading of time everywhere, making the clock the "one time zone" and "global clock". Thus, time zone math can be eliminated.
If I need a meeting at N:30 for example, it may be in the afternoon for me, but it could be at night for another coworker, and in the morning for another one.
Therefore, I still need to know their time zones to schedule the meeting at a time where everybody is available.
I have a feature for meeting planning. The clock then finds the best time for a meeting between the different location without the need to do any calculations on your end, or the other attendees' ends. With this feature, you can also choose the working hours availability. In the link above it shows the best time for a meeting between San Francisco, London, and Berlin for working availability between 8am and 7pm for everyone.
The idea is eliminate the calculations, and the confusing names of all time zones and daylight saving.
I already use calendly.com or savvycal.com for this purpose. I only need to think about my time zone.
On another note, how would you store your datetime in a database? If I understand correctly, we would need to save the location as well, so no real difference with a datetime+locale.
calendly and savvycal are mainly calendar apps and work well for the scheduling use case only. However, this is only one use case that a global clock can be used for. Another use case that those apps don't solve is global events e.g. SpaceX launching a rocket at 11am ET, or the Apple event yesterday at 10am PDT. If I don't live in those time zones, I don't know when those events are going to take place in my time. Thus the idea of eliminating time zones and replacing that with a global clock would solve many more use cases than scheduling.
There is no need to store datetime or locale for the clock to work. The clock knows where you are, using your sys time, or GPS, and according to that it rotates the UTC layer that is represented in letters according to you location. This means the clock adjusts itself for you in order to give the right local-global (UTC) time mapping. And that's all done by the clock's algorithm that manages the rotation. The main reason I'm using letters instead of numbers for UTC is to distinguish between local and global hours, simply for better communication.
Hi Hussam. I really like the hTime idea! The compelling perspective on this, for me, is to see it as a planetary frame of reference for thinking about time. Of course there is UTC but we don't casually and habitually speak about UTC because it involves "conversion" (between our own TZ and UTC) and "disambiguation" (what what, are we talking about UTC here? gotta check the TZ, ah, yes). The way your hTime differs is that it uses new a new alphabetic nomenclature for the global time, so it carries the signal right on its face that it is this new system. Definitely a subtle point, but I think a reasonable one. It'll be great when hTime "faces" for smart watches are available. That would speed adoption by making it easier for people to start "living" in planetary time. Personally, I'm all about this planetary cognitive context in my own work, so I have sympathy for the challenges you're dealing with landing the message of the value that hTime offers. Good luck and keep it up, it's an important innovation.
6 comments
[ 50.3 ms ] story [ 2934 ms ] threadWhy? To simplify scheduling & communicating time when working globally. So no PDT, PT, CET, nor UTC +2 -7. UTC is already the universal time, but almost nobody is using it on a daily basis. The clock I'm building brings UTC back in a new way, a UTC integrated into the clock and rotates with you according to your location on Earth. The clock knows where you are on the globe and adjusts itself for you. This unifies the reading of time everywhere, making the clock the "one time zone" and "global clock". Thus, time zone math can be eliminated.
If you like to help & give me some feedback, please check it out on https://thehtime.com. Here is also an 8-min-read on the idea and the motivation https://medium.com/adventures-in-consumer-technology/introdu...
I'd love to hear thoughts and feedback. Thanks!
If I need a meeting at N:30 for example, it may be in the afternoon for me, but it could be at night for another coworker, and in the morning for another one.
Therefore, I still need to know their time zones to schedule the meeting at a time where everybody is available.
https://xkcd.com/927/
I have a feature for meeting planning. The clock then finds the best time for a meeting between the different location without the need to do any calculations on your end, or the other attendees' ends. With this feature, you can also choose the working hours availability. In the link above it shows the best time for a meeting between San Francisco, London, and Berlin for working availability between 8am and 7pm for everyone.
The idea is eliminate the calculations, and the confusing names of all time zones and daylight saving.
On another note, how would you store your datetime in a database? If I understand correctly, we would need to save the location as well, so no real difference with a datetime+locale.
Am I missing something?
There is no need to store datetime or locale for the clock to work. The clock knows where you are, using your sys time, or GPS, and according to that it rotates the UTC layer that is represented in letters according to you location. This means the clock adjusts itself for you in order to give the right local-global (UTC) time mapping. And that's all done by the clock's algorithm that manages the rotation. The main reason I'm using letters instead of numbers for UTC is to distinguish between local and global hours, simply for better communication.
That's how it works :)