4 ms·
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
by garblegarble 5y ago
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.
- gerikson 5y agoMyanmar has a +30m delta too, as has Australian Central Time and Newfoundland. As mentioned elsewhere Nepal has a +45m delta. edit OK I crunched the numbers Country / Pop. / Timezone * Afghanistan 32.9M UTC+04:30 * Central Australia (Northern Territory and South Australia) 246.5k + 1.771M UTC+09:30 * India 1.353B UTC+05:30 * Iran 83.1M UTC+03:30 * Myanmar 55.6M UTC+06:30 * Nepal 28M UTC+05:45 * Newfoundland and Labrador 520k UTC-03:30 This comes out to around 1.556B people or around 20% of the world's population.
- Fnoord 5y agoCan this be used for profiling on the internet? Ie. if someone's clock is 15 minutes before the standard they are residing in Nepal?
- garblegarble 5y agoYes 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
- hhebbo 5y agoYou'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.
- ComputerGuru 5y agoThis 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?
- reidjs 5y agoWell, it works for my team, so I don't see a problem. Not everything needs to work for everybody in every circumstance to be helpful.
- hhebbo 5y agoI 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.