Image from Loic Djim
I’ve been thinking for a few years about the plight of the quickly reproducing alien termite race that is npm modules. It’s no secret that this community sets the records on module creation, adoption, and eventual abandonment.
In the face of rapid change, it’s a human reaction to cling to those things that are timeless. In honor of really useful tools, I think it’s only fair that I heap some praise on the tools that I use in every project.
These are the workhorse tools, the simple tools, the tools that attract little competition because they are best in breed. These are the projects that commit to semantic versioning, they write (and update) developer documentation, they write unit tests.
Most of all, these tools handle a complex and aggravating problem. In the best cases, they boil your problem down to one simple step. In the worst, they provide a consistent 80/20 solution designed for the rigors of a chaotic world.
After last year’s left-pad disaster, I cannot say enough for good, thoughtful modules like Moment Timezone.
Created in 2012 by Tim Wood, Moment Timezone is a helpful addendum to his earlier Moment.js library, with which most Javacript developers are familiar.
There’s not much to complain about with Moment.js. It’s a sensible, robust, and well maintained alternative to the confusing and limited date and time handling in JavaScript. The project has been so consistent and thoughtful I apply it like a native module. I never leave my home without it.
Moment Timezone primarily expands the Moment.js library to handle the universe of timezone related manipulations and conversions.
Other quick facts
If you want to learn a thing or two about the longevity of a project, check out the developer documentation. Moment Timezone passes my test with simple but thorough documentation explaining:
An emphasis on testing is critical for libraries that do complex and varied transformations. Small timezone bugs will likely go unnoticed, and you can only imagine the ripple effect into all manner of applications (financial, government, healthcare admin, communications, gambling, you name it).
The developer environment utilizes Grunt for build and test. Although Grunt appears dated at this moment. I would suggest a further vote in favor of the library on this point:
The creators and contributors are more concerned with stability of process than shiny object syndrome.
Here’s a quick look at how simple it is to get started:
If you learn nothing else today, learn this.
Most minimum viable products do not need to deal with the complexity of time zones.
One of the most useful cases for Moment Timezone is to set the default application wide. I do this (or a variation) in every one of my web or node projects:
In a browser app, you can set this in whatever version of init file you have. For an express app, I recommend the same for the main js file.
The default timezone will get you out of all the snafus arising from different timezones based primarily on the user’s machine (client side) or the server timezone (server side).
The biggest hangup I have experienced without Moment Timezone is the variable client and server times. Here’s the process:
I prefer the set it and forget it approach. If my MVP is targeting bars in NYC and listing their happy hours, I could just default my timezone to America/New_York on all applications. Confusion averted!
On top of that, the default timezone gives you a baseline for timezone conversion. If your app happens to need multiple timezones, there is no more reliable way to quickly get the conversion you need.
Moment Timezone and Moment.js have loads of more advanced features I have not touched. My use case is fairly generic. At most, I tend to deal with the American timezones, and quick one-off conversions. That, however, is the beauty of the library.
Check out the docs page and don’t forget to have some fun building things.