27 ms·
I believe I did the research. It's written in a blog post I published about time zones and the clock's concept https://medium.com/adventures-in-consumer-technol
by hhebbo 5y ago
I believe I did the research. It's written in a blog post I published about time zones and the clock's concept https://medium.com/adventures-in-consumer-technology/introducing-solutions-to-solve-the-mess-of-time-zones-cdf44a7ee4ae https://medium.com/adventures-in-consumer-technology/introdu.... That's what I'm trying to solve.
I appreciate your candor feedback. When users worldwide use the clock, they'll see both global and local times in one place, the global time will be "without" the minutes offset, and the local time will be "with" the minutes offset, so the mapping does actually work and I don't think it's broken in that sense. And as any project, there's always room for improvement.
- joshspankit 5y agoWhen 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)”.
- hhebbo 5y agoIt'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.
- joshspankit 5y agoThe 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)
- hhebbo 5y agoThanks for the clarification, makes sense.
- gregmac 5y agoI have to say, I don't understand what you mean by this. When I view https://thehtime.com/location?name=Canada+-+St.+John%27s https://thehtime.com/location?name=Canada+-+St.+John%27s currently I see: Time Locally: 14:52 Time worldwide: R:52 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?)
- hhebbo 5y agoWhat I mean is for example: India as you mentioned above in the list. On hTime https://thehtime.com/location?name=India+-+Mumbai 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 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.