When I first started writing software to handle time, I went into it with a naive perspective that it couldn’t be that hard. After all, it’s just time, and I’ve understood how that worked since elementary school! It took my first daylight savings time transition to disabuse me of that notion. I began daydreaming that one day all systems would fully run on UTC and people would adapt to that as a standard.
No more writing code to handle time zones in different regions. No urgent time zone library updates to account for new government legislation around daylight savings time. Being able to add and subtract time without having to account for crossing time zones…
It sounded great to me at the time, and sometimes when I’m neck-deep in tricky code, I feel that way still. In calmer moments though, I’ve learned that’s not a philosophy that serves me. When I talk to people about my birthday, a holiday, or give vague time measurements like “twice a day” or “first thing tomorrow,” I’m not speaking to them about timestamps. I’m conveying an idea that just happens to involve time. Time isn’t just a number; it is communication that is tied to our days and nights and the lived human experience.
A good software product handles, records, and displays time accurately. A great piece of software captures, stores, and displays time and date information in a format that conveys the full idea to the intended recipients. Good software works; great software communicates.
