Gregory's ServerThere’s a myth that working with date/time is hard. I think it’s trivial, but the myth persist nevertheless.
If you believe in it, too, can you share a case where working with date/time is indeed hard?
 20 comments
@antoinevg on the topic though, I had to change my TZ on Android once to a different city for ~year because tz rules changed in mine but Google was not serving updates @nikitonsky it's not hard if you not making a Calendar app. But you should know what you are doing anyway. E.g. saving timestamps for the future events is not the best idea. Timezones might change either because of DST or some whim of a government.  @nikitonsky Japan launches a Mars Rover. The landing is hard, so the computer reboots, the clock resets, and it sends a message with timestamp=0 While the message is being transferred to the Earth, the Japan Emperor dies, thus resetting the current year to 1. A system that receives the message needs to display in a human-readable format when the message was produced (recomputing it if corrupted) and when it was received. @nikitonsky Another example: you are writing a program for students to show important historical events on a calendar. On which day would you display the Russian Revolution of 1917? @bemyak Oh, we Russians know this very well! It’s a famous “October revolution” that happened on November, 7, 1917 @nikitonsky Actually, when it was happening, it was October for everyone. The date was changed retrospectively when Russia/USSR switched from the Julian calendar to the Gregorian year later. So on the date of revolution the Georgian calendar was not a thing 🤷  @nikitonsky our concept of time is based on vibrations in matter and the motion of celestial bodies that wobble and accelerate. Maybe arithmetic on top of a Gregorian calendar is trivial, but how’s your general relativity? @nikitonsky All the pain I've had has been from interfacing with old-ish mysql or oracle systems with timezoneless "yyyy-mm-dd hh:mm at whatever the local timezone happened to be locally at that time" time entries. In no way "hard" hard, but annoying and yucky and possibly ambiguous when you need to convert it to a proper, actual point in time. @nikitonsky sometimes you need timestamps, sometimes you need wall clock times, sometimes you need a date without the time zone/offset information, and so on. Also, time zones and offsets are different things. The struggles I’ve experienced are when an engineering team is resistant to dealing with these differences. “Just use an ISO-8601 timestamp everywhere and we will be fine!” Sorry, but there are just some things that won’t work for.  @nikitonsky While I feel like working with date/time is fine while using something like "java.time" package, there is enough things that can go wrong with time that definitely disqualifies it from being trivial. Even timezones and daylight saving time introduces enough complexity to mess up something easily like storing an instant for future event or scheduling something based on hours.  - government removes daylight savings - clock starts showing wrong time on an old Android device - user fixes by adjusting system time manually - now they have incorrect system time on their device (compensated by local tzdb error) - you build mastodon client that shows relative times – i.e. 'posted 5 min ago' - post time comes from server and is 'correct' - how to render this relative time on such devices with 'incorrect' system time? @odnoletkov well it’s still going to be correct, it doesn’t really matter what tz user uses @nikitonsky to show relative time like that you need to compare local and remote times – that would not work when local time is way off @nikitonsky your `System.currentTimeMillis` is off by 1hr. You have `post.timestamp` which is correct. How do you render label like 'posted 5 min ago' properly? @odnoletkov No, System.currentTimeMillis is never off by an hour, regardless of timezone. In fact, it doesn’t even change when you change time zones |
@nikitonsky That time I made the mistake of using a VPN on my Macbook and the next six months everything, even remote websites was off by one hour.
Once Apple decides you're in Europe you can't even override the Timezone settings manually in System Preferences.