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.
