When building solutions for others, there are certain problems that we face that – although they’ve been solved – can still be a challenge for us to deal with.

For example, you’ll often hear programmers complaining about regular expressions or maybe you’ll hear someone complaining about working with timezones.


I’ve been heads down on the latter for sometime now in a project and even with solutions like Moment.js, there are subtle nuances that must be taken into account when dealing with dates and times.

There are plenty of other examples, but the point that I’m really working towards is this:

When we’re focused on problems that have a number of subtle nuances, I think that we often tend to overlook some of the simpler things that can be done to address the issue.

In my case, I’ve been in the trenches with timezones, offsets, and other subtleties that come with working with dates and times that I’ve tried to over-solve a problem.

Don’t Over Solve Your Problem

Whenever I work on a problem for too long or focus on a problem for too long, I often find myself trying to do too much work on behalf of the user.

For example, in the case of working with dates and times, I find myself trying to take care of the timezone component on my own rather than having the user simply select the timezone in which they’re located from a list of options, or by reading it from a value saved in the database from a pre-existing value.

Einstein’s Razor

There’s a quote that’s often attributed to Einstein that says something like this:

Everything must be made as simple as possible, but no simpler.

In the world of programming and design, variations of this quote or this idea are pretty easy to come by, but I think that we read them so much that we often dismiss this, treat them as clichés, or recite them without actually trying to apply them in our day-to-day work.

And who can fault that? I mean, they are used everywhere and we do see them a lot so it’s not unreasonable to think that we skip over these ideas whenever we’re working on something. But things like this often become popular because they carry some kind of weight or have some kind of merit.

In the context of what I was talking about above – that is, working with dates, times, and timezones – it’s an attempt to over-solve the problem by trying to take care of the timezone factor at the code-level. There are a number of variables that we can’t often predict (server time, client time, location, the international date line, daylight savings time, and so on) all that can be eliminated by simply exposing one more option to the user.

A Decision For Options


Specifically, just asking them to state the timezone in which they are located absolves us of having to trying to nail down all of the variations on our own.

No, I’m not a fan of giving users a lot of options (even as a user, I’d rather not have a lot of options), but when it comes to giving the user a choice between having one extra option and a correct solution, and one less option with a sort-of correct solution, then I’d choose the former every time.

Sometimes though, it’s hard to get out of the trenches enough to make that decision.