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.
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?
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.
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.
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 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.
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.
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.
That's very kind of you to offer. I don't think any clock is going to help people who make meetings run over or are always late! I really like your solution, though. It's very neat.
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.
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.
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
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.
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 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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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!
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.
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 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.
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.
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.
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.
Would be nice if "BrandonText-Light" font supported `font-variant: tabular-nums` — this would prevent digital clock display from slight horizontal jumps on each second change.
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.
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.
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?
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
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.
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.
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.
> 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...
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.
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".
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?).
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.
> 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 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.
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!
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 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.
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.
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.
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.
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.
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.)
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?
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
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.
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.
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?
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.
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.
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.)
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.
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.
200 comments
[ 2.8 ms ] story [ 218 ms ] threadOne 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.
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.
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:
The actual local time there is 14:22.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.
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.
(And as other comments have noted, this breaks down in utility with 15/30min TZ offsets as well as when crossing the date line.)
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 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.
Also, obligatory XKCD: https://xkcd.com/927/
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...
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.
https://en.wikipedia.org/wiki/12-hour_clock
> 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.
Distinguishable figures are awesome.
Really this is just an offset in letters. Make the offset in numbers. I love the inner clock face idea.
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):
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.
Random modern example of 24h watch
https://www.oris.ch/en/watch/blue-eagles-limited-edition/01-...
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.
https://www.youtube.com/watch?v=-5wpm-gesOY
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?
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.
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.
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!