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 on DST — yeah, the damn Daylight Saving Time. all-in https://xkcd.com/1883/ You see, this week is special for time nerds: Europe’s DST just ended, but here in 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. Freedom Land This has some implications. First off: your schedule is completely borked if you have recurring meetings . 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 in an edge case this week has probably many developers worth their salt shitting their pants right now. across the pond living 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 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. some 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 which is 543 years ahead of the Gregorian calendar? Well, neither did I, duh. Buddhist Calendar This is just a funny example, but shit gets real really fast when you dig a bit deeper: Did you know that ? What about the fact ? Or the fact that ? Samoa changed timezones not once but twice, gaining and then losing one full day that Europe might end DST from 2019 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 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 . thousands of years Neil deGrasse Tyson does 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: . Did you read the preceding paragraphs? Do you really want to maintain dynamically changing data structures plagued with edge cases that evolve with, well, ? 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 — You don’t need to prove anything to anyone building your own. Never, at no time, under any circumstance try to roll your own in-house date/time library time free . . Some basic concepts to look into: Timezones (duh), , localized dates, durations, recurring events, etc. — If you take just one thing away from this article, make it this one. Try to understand how date/time actually works Don’t program by coincidence, program deliberately epoch Here is a brilliant primer on all those concepts Use clocks for testing dates and time Thanks for reading. The End. * BTW The (and only) answer to “how to write a date” is , you’re welcome most correct [YYYY-MM-DD](https://xkcd.com/1179/)