Logo for Nemo Nisi Mors
Friends in need
Random Quote
Programs must be written for people to read, and only incidentally for machines to execute.
Hal Abelson and Jerry Sussman
Modified 2019-11-03T12:07:16Z

If you, as a system developer or product owner, have to handle timestamps in your system, you have to think about a few things. Especially if you plan to show your users these timestamp values.

Note: A timestamp denotes a unique, unambiguous point on the timeline.

UTC is your friend

As long as we use our current timekeeping system with the utterly complicated time zone rules, the Coordinated Universal Time (UTC) will probably be your best choice.

  1. If you decide to not use UTC everywhere, think again.
  2. If you still want to use other time zones than UTC, please, take a walk around the block, and then reconsider your decision, by reading about pros and cons with time zones.
  3. Okay, if you are sane, but still want to throw yourself into the time zone mud, you can at least consider the following:
    • Are you going to store all your timestamps in UTC, otherwise think again. (With all I mean exactly all, not most, not some, not the majority.)
    • Are you going to show your users any of your timestamps without explicit time zone information, think again. Or better yet, never do this.
    • When using different time zones, please skip the useless abbreviations (eg CET, EST, IST). Also avoid to only use identifiers (eg Europe/Stockholm, America/Los_Angeles), since they lack actual offset information. Make sure to always include correct offset information.

Formats for clients

Only allow one format for sending and receiving timestamps. Never implement APIs that allow several different formats for defining timestamps, where you are responsible to parse and convert these timestamp formats correctly. If a client wants to use obscure timestamp formats in their own special locales, that should be the burden of the client, not the burden of your system.

The best format out there at the moment is the ISO 8601 extended format (for example 2019-01-23T01:23:45.789Z), so there are no reasons to ever use anything else.

Displaying formats

With the same arguments as above about the burden of your system, I really recommend to only use the ISO 8601 format for displaying timestamps.

Supported languages

A note about the maintenance nightmare you will encounter if supporting several languages. I really recommend to only use English as language. Otherwise you will have a hard time keeping all your translations up-to-date and with quality, especially if you are supporting languages that you are not fluent in.

If you decide to support several languages and formats, never ever mix language and format together. Always make sure that a user can configure language and format independently.

Conclusions

As always, keep it simple. It is difficult to be agile, when walking around in mud up to your neck.

If you use UTC and one common format everywhere your life will be a walk-in-the-park and your users will unambiguously understand the timestamp values they are seeing. The other paths may be dark and cumbersome and you have been warned.

First published by Anders Gustafson 2018-09-01