Hacker News Reader

Comment by midasuni | Hacker News Reader

Nepal is broken (it’s 45 minute offset from norm)

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.

View on HN

It's like UTC but worse. If people need to learn something new, it's better to teach the basics of ISO 8601 to everyone.

Intentions are good, but I found this system confusing and not useful for me.

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.

Thanks for the feedback, I appreciate it! May I ask why do you find it confusing? I’d love to improve it.

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.

Have you thought about including an additional identifier for the day too? That might help in addressing the edge cases that fall on different days.

Good idea! I had it before and removed for simplicity, but I'll put it back. You're right, it'll help with the edge cases.

Why cant we?

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.

I'll just leave my common advice here.

- 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).

For the info, I just fixed the time zone offset for Nepal in the algorithm. Check it out here https://thehtime.com/location?name=Nepal+-+Kathmandu and please let me know if it works.

Fun fact: my local vaccination centre used Nepal time clock as the “minutes” part for a clock that was 15 minutes slow. Why?

That clock showed you the vaccination time that was now safe to leave, having been observed for 15 minutes.

That's an interesting use case! :)

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!

Reply on news.ycombinator.com