Show HN: Combining UTC and local times (time zones) in one new clock
thehtime.com
thehtime.com
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.
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.
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.
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.
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.
- 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).
That clock showed you the vaccination time that was now safe to leave, having been observed for 15 minutes.
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.
Would you give hTime a go and test it for some days? I'd love to hear more feedback.
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.
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)
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?)
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.
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.
I can simply change the letters to numbers, do you think that'd help?
That being said, the interface should really put the location closer to the letter ring, because it's somewhat easy to forget you're looking at a localized mapping and what the letters mean, since they are in another UI element.
"So all users when they look at the clock at the same time no matter where they are, they'd see the same time."
This is true of any clock (unless fancy optics are involved, or we get too deep into physics), two people looking at the same wall clock will see the same time. The problem is that they might want to interpret what they see in a different way. Both UTC and your htime thing are a way to solve that problem.
Leading with a letter helps people not start reading as a local time, whereas with 8061 formatted times you only notice it's not in your own locale at the very end of the time. Depending on your use one might be better than the other. Unfortunately time requires that I remember one additional piece of information, namely UTC: X=24, before I can index into the alphabet and calculate the difference myself, whereas UTC simply requires I add the offset to the time and move on with my life.
What I actually meant by "all users when they look at the same clock at the same time" is all users in different locations would see that time is the same in letters. For example everybody worldwide would see that time now is R:24.
I agree on the last piece as well. I think using it for some time will prove what would be better for the UTC ring, letters or numbers. Each has its own benefits and flaws as you mentioned.
Would you like to give hTime a go and test it for some days? I'd love to hear some more valuable feedback.
> Would you like to give hTime a go and test it for some days?
Perhaps... but to be perfectly honest, I haven't yet decided if I love or hate this idea yet.
To give you an idea about how I'm thinking of this, first and foremost hTime is a time format, meaning it's just some mapping of letters to a local time's hour. The most interesting part to me is that, since I read left to right, I also see the locale information first as opposed to last. You can rightfully argue that the locale is needed to interpret the rest of the time, so this is the correct way to format world times. On the other hand, world times are the same as local times for everyone within earshot of me, so I would never bother prefixing things locally.
Secondly, it's a tool for helping people with world clocks and scheduling.
My concern is that there are better solutions to the first thing, despite any improvements made to the second. For example, would it not be better to simply prefix the timezone information directly? For example, it's currently Z22:36. We do use more characters, especially if we want to be able to extend this to local times too (e.g. +5-03:36). I might be tempted to start trying to lay this out so the math works out for (+5) adding directly to the hour as 5+03:36 = Z22:36, but now I realize a larger problem with all this... dates.
Placing the offset in the middle of the full time string 2021-10-20 together with 22:36 requires thought. I'm tempted to like it, because the timezone offset is obviously much more related to the time than the date, but moving it closer to the date really couldn't hurt, could it?
Take either hTime, or my example:
- 2021-10-20+5-03:36
- 2021-10-20Z22:36
- 2021-10-20Q:36
We just replace the 'T' in ISO-8601 with the 'Z' part or with nothing before an hTime. Now I get to complain that 'Z' looks way too much like 2... Meanwhile https://thehtime.com/ hasn't loaded and I can't remember the mapping for the current time, so I don't think I've written my example consistently.
I think that's the part of hTime I like the least. I have no hope of decoding it without knowing what it is. Meanwhile an 8601 datetime stamp can be somewhat inferred. So to quote you, if I may, "[the] main thing is we find a good way to get rid of time zone math!". But we can't get rid of the time zone math... it's just either arithmetic, or a special code.
Anyway, I'm just bored right now over here thinking on paper. Always glad to hear that my feedback is somewhat useful. Thanks.
The feedback and arguments are highly valuable. I really like the way of thinking about time zones in your explanation.
As you mentioned, hTime is a time format and a tool, which I like describing as a "clock". A clock combines both concepts. Clocks is a way to measure, read, and communicate time. With hTime, that's the goal. Now with the formatting piece from your examples "2021-10-20+5-03:36, 2021-10-20Z22:36, 2021-10-20Q:36", all of them actually look and read the same somehow. To be honest, Z22 or Q isn't that big of a difference IMHO. The difference is the math still. It's very simple math, just adding or subtracting, but it gets confusing when more than one time zones are involved. Take a meeting between 2+ time zones. The question then is: What is the best time to have a call between 3 different locations? The math, as simple as it is, get a bit confusing to find the best time. I've been in several situations and heard that many users of time zones miss a call by +-1 hour only because they miscalculated time zones.
The other aspect is time communication. That's the case when a deadline or an event is happening somewhere around the world. We usually communicate time using 3-4-lettered time zone names that make it even harder to remember. For example the Olympics, there was a game at 2pm Tokyo time; what is that for the rest of the world? Before doing the math, we need to know what Tokyo's time zone is, what the Z or UTC equivalent is, and then do the simple math. It's almost always a 2-step thing. With hTime as a clock, it's only the mapping. So if they say the game is at R:00, I have the mapping in my head and done! 1 step. With the example of a meeting between 3 time zones, that's then 5-6 steps with Z or UTC, but with hTime, it's again 1 step only. That's the kind of thinking I have behind "no more time zone math" and the idea of hTime's clock with the mapping between global and local times.
Happy to hear what you think
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...
Also, obligatory XKCD: https://xkcd.com/927/
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.
“Oh, it’s O:56, I better prep for the meeting at P:30”
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.
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.
This is already answered in the post you are replying to, so I assume this is you demanding an external source:
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.
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.
Would love to hear your thoughts on the rotating UTC layer vs an extra UTC layer + hand.
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.
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?
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
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
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.
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.
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.
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.
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.
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.
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.
(And as other comments have noted, this breaks down in utility with 15/30min TZ offsets as well as when crossing the date line.)
I think simple text list of different locations and their current local time is much easier to mentally parse.
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):
In your clock, it "looks like 10am" instead of 8am because of the accumulated lifetime repetition of reading traditional 12-hour clocks.
Random modern example of 24h watch
https://www.oris.ch/en/watch/blue-eagles-limited-edition/01-...
Looks really nice and I hope you and your process success, you're fixing a problem
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.
I believe the barrier-to-entry with a 24-hour, 60-minute, 60-second system is simpler than Beat.
I'd suggest a good alternative is to just stick with Google Calendar/Microsoft Outlook and/or WorldTimeBuddy.
They're easily confused with I and U, respectively.
You never know when a standard is based on a single person’s subjective choice. I think it’s fascinating personally.
IMO: Something in the html needs cleanup. Depending on my window size, elements are always overlapping. (I'm on Chrome on Windows, with uBlock.)
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.
BTW: Have you ever written a Fitbit watchface? They're pretty easy.
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!
How would you implement your idea? Do you have any sketches or notes about that?
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
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.
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.)
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?
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.
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.
Especially as the only cookie the site sets, is the one that you accepted cookies :D
It’s also an annoying dark pattern.
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.
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.
Really this is just an offset in letters. Make the offset in numbers. I love the inner clock face idea.
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.
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.
(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.)
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.
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".
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.
> 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.
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.
You just opened up Pandora's Box though... there are so many corner cases
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.
Portrait mode on chrome / desktop is broken pretty badly.
Patent pending - what does this mean?
Distinguishable figures are awesome.