Hacker News new | ask | show | jobs
by anileated 132 days ago
You would need to know that person's working hours, so I don't see how you are avoiding something.

Sure, if you talk to someone there for the first time, you would need to learn what time is generally day/night. However, you will know that 2-3 times in. Just like you would automatically know that now it's summer in Oz, or 3 hour short days near Arctic circle, if you talk to anyone from there even very occasionally.

Case in point, we have global calendar with no problems.

1 comments

My point is either way you need to memorize some info in the first couple of interactions and it really doesn't make sense to go through all of this change to just memorize a different thing.

If you really need to coordinate something across many timezones, you currently have the option to use UTC to specify the time.

Following the sun also gives a lot of context. (i.e. if my flight to China lands at 9p local time, I immediately know that it's going to be night, but if my flight lands at 1PM UTC, I really have no context as to what time of day I'll be landing)

> My point is either way you need to memorize some info in the first couple of interactions and it really doesn't make sense to go through all of this change to just memorize a different thing.

It's at least to make time management in systems much less error-prone and complex, among other things.

> if my flight to China lands at 9p local time, I immediately know that it's going to be night

What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean something like "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).

> It's at least to make time management in systems much less error-prone and complex, among other things.

I'm sure people deal w/ more complex issues, but 90% of it is covered by storing everything as UTC and doing the conversion on the frontend.

> What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).

It implies a lot, including that less things are likely to be open, it's likely to be dark, and that I'll probably want to get to bed within a couple of hours to wake up for whatever I'm doing the next day at a reasonable time in the morning (i.e. how to adjust to the daylight cycle there).

Things you will have in context when traveling: "it's going to be cold", "it's likely to rain", "it's going to be government conference so there will be extra delays with transport", "it's going to be %holiday% so everything's going to be closed all week", etc.

You're so used to it you don't even question that, and if you add to that "@x is when sunset usually happens"... somehow I think the world will not come crashing down.

I don't think the world would come crashing down, but what's the point if it's just another thing to memorize?

The total cost/effort of timestamp translation in systems is not as high as people make it out to be.

> just another thing to memorize

Not knowing what time it is for my Australian colleagues at all without checking my phone every single time is worse. Remembering N timezone offsets (remember DST and half-hour offsets, too) is worse. Doing UTC translation or adding "my time/your time" every time is worse.

If you talk mental overhead, current system is like 10x of that than global time.

We agreed to meet at "8pm their time" but unless I literally put it into my TZ-enabled calendar app every time the chance I mentally translate it to my TZ wrong is unacceptably high. With global time, meeting would be @123 and that's it. I can keep it in my head or write it down on paper, no confusion and full precision every time. I don't even need to know if it's day or night if it's a remote call with the other side of the Earth, maybe me or my colleague works late, who cares, but I know what time it is there at any moment.

> is not as high as people make it out to be.

It's not just timestamp translation and all the errors that come from that, it's all the rest of it, waste standardizing timezones and moving them around, having to convert time all the time, missed meetings, etc.