The Frustration of Dealing With Time

Have you ever speak with a friend from a different time zone? Usually, it's not a problem. If I tell my friend I'm going for a walk in the afternoon, she (consider my friend is female) can understand I mean by "my afternoon" and not "her" afternoon. But what if you tries to agree on a time, say, the next time we meet? Say, you say, "let's meet on next Tuesday 10 am (my time)", but your friend heard "let's meet on next Tuesday 10 am (her time)", an agreement is broken. "Her time" isn't the same as "my time". How do you deal with that time differences?

This adds extra burden if you live in a country which have Daylight Saving Time. For god sake, when one lives in a region without Daylight Saving Time*, and another friend lives in a region with Daylight Saving Time, the person living without DST won't automatically track when does DST occurs, so if the person with DST doesn't inform the other person without, the person without is sure to miss the reunion by an hour. (Missing an hour early is fine, as you might remember DST and attend again an hour later; but if you're one hour late to the meeting... GG)

Assuming you're not the "too lazy I don't want to deal with it anymore", in which case you just tell your friend to not call you until you're in the same time zone as him/her, the ultimate problem to time management is "compare to a single time". That means, one party have to give in to use the other person's time, to achieve consistency. In the case of 2 person only, you give in to one person's time. However, in a large group of people, each living in different time zones, we need a constant time to compare to. Usually, this is compared to the "Coordinated Universal Time", a.k.a. UTC (which slices through Greenwich, so it has another name of GMT+0), as a standard. Hence, everyone not living in UTC time zone shall have to do the math themselves, and search up what time zone they're in! It's time to pick up your math back!!! Don't throw them away yet!

Similarly for programming. Recently, one tries to write a program only for people living in one's country, by changing the backend (usually server, not sure if web3 node can change time when it's on other's computer) time to one's local time zone; but it starts to have some problem. First: it seems like the database won't recognize time zone, so it assumes everything is saved as UTC time. However, my time zone is GMT+8, and one set the program to recognize time as GMT+8 time. While most program recognize between the time difference, some program doesn't. Basically, for unknown reasons, this happens:

Party A: "Here, party B. This is 20:00 GMT+8."

Party B: "Ok. For consistency, I'll save it as UTC time. So, 12:00 UTC".

Now, some database doesn't have a "time zone". The flaws now comes in when party B retrieves the time.

Party B: "Hey, Party A, here's 12:00... Umm... I forgot if I saved it in UTC or GMT+8."

Party A: "Oh right, 12:00. Well, since I live in GMT+8, I'll assume it's 12:00 GMT+8."

See the flaw? A time zone not sync to UTC will cause problems like this. For now, the difference to the actual time is 8 hours. Consider you repeatedly save this over and over again. The second time, you'll get 8 x 2 = 16 hours difference from original, then 8 x 3 = 24, and 32, and 40. Time keeps going back with a single save.

What if you save in GMT? Well, 0 x 2 = 0, 0 x 3 = 0; so, who cares how many times you go back and forth, when everything is zero!!!? Go ahead, you can add and subtract as you like, it'll always be the correct time.

But how do we face the user? Of course you display time to the user in their respective time zone. This is what the Date object in javascript does. Your server most probably return an ISO string (the international standard to represent date and time) to you, something like this: 2023-04-21T14:11:56, so anything before the "T" is a date object, and anything after is HH:MM:SS (sometimes you have milliseconds too, but let's ignore that). However, if you read this into your new Date('2023-04-21T14:11:56.684'), it'll give the wrong result, as it try to localize to your time zone. Hence, we just need to add a "Z" at the back, so into "2023-04-21T14:11:56Z", which tells javascript the date is in UTC time. This way, things will be easy to handle. Backend always UTC time, frontend localizes to each others time zone.

Of course, sometimes you want to search for things in other people's time zone. That would be more tricky to handle, of course, as you have to deal with "forget about localization to your time zone and localize to the other person's time zone". Otherwise, mostly you search in your time zone. Say, the ticket is released in Singapore 8am. If you live in the UK, you'd mostly try translate it to your local time. Then, if you want to search for time range, usually you want to search "by my local time" rather than "by their local time", unless in special cases. So it makes sense to perform search in your localized time zone, in most cases.

Time, we take so much advantage of it that we think we know everything about time, because it's so easy!!! But now, you know something more difficult about time. Even things as simple as time can be... not so simple. And if you want to agree on a time with a friend living in a different time zone next time, it's time for you to learn how to calculate time differences and agree on a "universal time", not just local times!

Remember to Like and Subscribe!

*countries near the Equator doesn't have much time changes, my country about 10-15 minutes difference hence doesn't trigger "saving time", and weather is all-year-summer

Extra

Even worse, time zone now and time zone before isn't necessarily the same. For example, Singapore time zone is now +0800, but during year 1900, it was +0655. Standardization to a "more beautiful number" (and more easily communicate time with countries in Southeast Asia, without converting time zones across countries) happens latter.