[Guest Post] Datetimes Suck

Peter Skinner spills the haterade on a vital, yet terrible, concept in programming.

This guest post was written by Peter Skinner, a Staff Javascript Wrangler with a decade of start-up experience. He likes long board games on the beach and short CI pipelines. You can find him here, when he isn’t busy shaking his head at whatever BS flavor-of-the-week framework he’s being asked about.

NextPath Mag is curated by Robby Grodin, founder of NextPath. Check out our coaching offerings, watch NextPath TV, ask me an anonymous question, and don’t forget to have a wonderful day.

Datetimes Are The Worst.

Dates and times have been the bane of my existence since I started coding in javascript over a decade ago. They reared their ugly heads for me again recently when I started to redo a very old and very untouched part of our application related to scheduling appointments. After many irritating bugs and requests, I decided to take a therapeutic axe to our scheduling systems and fix them “once and for all.” In doing so, I learned a lot about why we ended up in this mess. Here’s a summary:

Let’s break these down one at a time.

Inferred Timezones

In SQL, datetimes are typically stored in ISO 8601 standard format: YYYY-MM-DD hh:mm:ss. Notably missing from this is the timezone. SQL expects you to store all datetimes in UTC timezone and figure it out when the date gets passed to an application. When a date string in this format is passed into a standard javascript Date class, it assumes your timezone is in your browser’s local time, not UTC. More on javascript’s infuriating vanilla Date class later, but let’s talk about how to fix this particular issue.

Unfortunately, any solution requires some intervention. In order to fix the timezone issue, we need to append timezone information to the date string when it comes from the API. In doing so, we have to either A) assume any datetime string without a timezone is UTC or B) fix this on the API side as part of our middleware processing datetime strings. The second one is way more complicated, but either way once a datetime string is actually used it always needs the timezone information applied.

Additionally, when saving datetime information to be stored in the database, you have to make sure you convert the datetime BACK to UTC to ensure the database will store it properly. To cover these bases, I created a standard parsing function which checks the inbound date string for timezone information and normalizes our date strings.

Dates Are Not DateTimes

In theory it’s extremely obvious to say that Date is only part of DateTime. I mean, it’s in the name. In practice, we assume they are similar enough that we use them interchangeably, leading to problems.

The most important problem we run into is once again caused by vanilla javascript Dates. Ironically, the Date object actually only works in DateTime. There is no ability to take Time out of the Date class. This may seem like semantics, but let’s take a look at an example. Let’s say we have an appointment scheduled for March 3rd. Javascript will take this date: “2026-03-03” and assume you mean March 3rd at exactly midnight in your local time. Functionally, this is now indistinguishable from an appointment scheduled exactly at midnight in your local time. If you were intending on separating appointments with a set time and appointments without, you can no longer tell the difference without going back and parsing the original string. Trust me, this can get extremely frustrating, especially when attempting to convert this back into a database string.

In many cases, our application did not properly remove the time and timezone information from their strings during save, so our database became a mess of mixed date and datetime strings. To help resolve this, I added date flags as arguments to the date parsing utility functions. These flags strip time information from the DateTime being passed on both ends to ensure we can start to save the proper date information and still parse the existing mayhem in the meantime.

Vanilla Javascript Dates

Javascript’s Date class is a mess. It was built for a time when the internet consisted of funny little geocities sites filled with GIFs of hamsters dancing and a clock in the middle. The Date class was never made for multi-national corporations. In a great example of this, both Day and Year variables in the Date class are 1-indexed while the Month variable is 0-indexed. Internally, January 23 is stored as 2026-00–23. Pure madness.

To make matters worse, one of the primary packages we use as a baseline for our Date and Time scheduling components made the decision to use vanilla javascript Dates to try to keep their package “accessible” and “lightweight.” Instead, it makes the package rigid and full of bugs. Especially since they store their Dates privately inside the components. This works great when the user is starting fresh every time with a new Date in their local timezone. This becomes a total dumpster fire when you attempt to pass a UTC-based date string in as your starting time. I highly recommend using Luxon in an attempt to avoid the Date object like the plague.

“I love Daylight Saving Time” - No One Ever

I think we all know how much of a pain DST can be for applications, so let me just highlight one fun example of how it can become a silent killer. In our application we had one selector used for choosing what date your appointment is on. Separately, we had a different selector for what time your appointment should be scheduled. The time selector, being separate from the date selector, used today’s date as the Date baseline for the DateTime. Unfortunately, this caused a massive issue for us when DST “spring forward” happened. It turns out, if you schedule an appointment from the east coast prior to DST (tz shift -5:00) for a date after DST (tz shift-4:00), your appointment is off by an hour. Imagine the look on our faces when suddenly every appointment was off by an hour. This bug passed right through our tests, because it’s not top of mind to test the DST border. We now have exhaustive tests for DST borders.

In summary, DateTimes suck, but they’re here to stay. Shoutout to XKCD for providing relatable comics on this topic.