Better know a module: Moment Timezone

Trevor Ewen
Aug 29, 2017 · 4 min read
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.

Moment Timezone

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

  • 32 contributors on Github
  • 31 releases
  • Maintains an active issues board
  • Has a great documentation page here
  • Runs live timezone tests on the docs page here!
  • Has a really cool interactive timezone visualization that looks like this:

Developer Setup

  1. Dependencies for developers
  2. Running tests
  3. Compiling the robust timezone data
  4. Contributing new zones
  5. Building tests for new or existing timezones

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:

The MVP use case

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.

But wait! There’s more…

Check out the docs page and don’t forget to have some fun building things.

HackerNoon.com

#BlackLivesMatter