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.

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

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.

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