This week is an edge case, or why dealing with time in code sucks

This morning a reminder from a todo app interrupted my breakfast ritual at 8:00 AM. It’s not a big deal, if it weren’t because I had set the reminder for 9:00 AM. A few minutes later Google started giving me suggestions on how to get to work, when it normally starts bugging me an hour later… what the hell?

I can’t be sure, but if you put a gun to my head and pressed me to bet for a cause, my chips would be all-in on DST — yeah, the damn Daylight Saving Time.

https://xkcd.com/1883/

You see, this week is special for time nerds: Europe’s DST just ended, but here in Freedom Land we don’t end it until this next Sunday — because it would be too easy, boring and coherent to end it at the same time as Europe — so right now we are in one of the only two weeks of the year where Europe and America are one hour closer.

This has some implications. First off: your schedule is completely borked if you have recurring meetings across the pond. Second, and most important if you are a developer: you better make sure to have controlled for this edge case in your code — For the normal people reading this, an “edge case” is what we developers call something that happens very rarely and, by extension, will probably not work; and the fact that we are living in an edge case this week has probably many developers worth their salt shitting their pants right now.

See, in a utopian scenario, developers would fully understand how date/time works and the software they write would be bug free. In a less ideal scenario developers will have pretty good knowledge of some of the edge cases associated with time/date, take them into account and test them out. More realistically and talking from experience though, we just wing it most of the time: we write the best code we can, test all the cases we can come up with at the time and our butt cheeks clench when we ship the code to production.

Why is that? I just think not many developers understand how to work with time — it’s just not the kind of thing they teach you in Bootcamps, let alone in College — we’re left to fend for ourselves and we learn by trial and error. My first fuck-up with time in software made customers book hotels for the year 2557 instead of 2014. Yup, 543 years off. “That’s not an edge case, that’s a fiasco” I hear you thinking. Well, hear me out. The bug only happened in the Thai version of the website. Did you know that Thailand follows the Buddhist Calendar which is 543 years ahead of the Gregorian calendar? Well, neither did I, duh.

This is just a funny example, but shit gets real really fast when you dig a bit deeper: Did you know that Samoa changed timezones not once but twice, gaining and then losing one full day? What about the fact that Europe might end DST from 2019? Or the fact that days don’t actually have 24h and we need to compensate for that every now and then?

That makes me wonder, isn’t there a better system to handle all this shit? Is this really the best humanity can come up with? In short, yes. It took us thousands of years of tweaking and standardization to get where we are today, so we have to work with it. You don’t need to believe me, I don’t know what the hell I’m talking about, but I think .

Ok, this is starting to sound like a rant against time(zones?) which is not, so I’ll just wrap up with some pretty basic, common-sense advice I learned over the years of dealing with date/time in software, from yours truly:

• Never, at no time, under any circumstance try to roll your own in-house date/time library. Did you read the preceding paragraphs? Do you really want to maintain dynamically changing data structures plagued with edge cases that evolve with, well, time? Not to talk about the localized dates: We can’t even agree on how to write dates FFS*! Date/time libraries have to deal with stuff from nightmares, so just let Open Source work its magic and just leverage the work of the true heroes of this whole thing: the maintainers of date/time libraries that you can download and use for free — You don’t need to prove anything to anyone building your own.
• Try to understand how date/time actually works. Don’t program by coincidence, program deliberately. Some basic concepts to look into: Timezones (duh), epoch, localized dates, durations, recurring events, etc. Here is a brilliant primer on all those concepts — If you take just one thing away from this article, make it this one.
• Use clocks for testing dates and time

Thanks for reading. The End.

* BTW The most correct (and only) answer to “how to write a date” is [YYYY-MM-DD](https://xkcd.com/1179/), you’re welcome