Display Date and Time: How to Do It Right

We come across them dates and time… well, every day. When it comes to the Web, you can spot them in your mobile apps, in emails, in your messaging apps and many other places. Yet in spite of seeing date and time every day and everywhere, we have yet to adopt a universal format for it.

For example, if I write 10/05/2015, you can never be sure if that "10" is the month or the date unless I tell you where I am from. Sometimes the format changes, other times the language.

It is of importance that as web developers we pay attention to the date and time that we deal with in our projects, so that we can cater them to different geographic inhabitants without any conflict. In this post we’ll be discussing what to avoid and what to embrace when it comes to displaying date-time.

Understanding Global Standards for Time Representation

If we choose not to adapt date and time formats for various international audiences, what approach could we take? Opting for a universal format might be the solution. At this point, it’s important to note that the World Wide Web Consortium (W3C) endorses the use of the ISO 8601 date format in conjunction with the UTC timezone.

Introduction to ISO 8601

ISO 8601 sets the international standard for representing dates and times numerically.

The standard format for a complete date is: YYYY-MM-DD, for instance, 2015-07-28.

  • YYYY = Four-digit year
  • MM = Two-digit month (01=January, etc.)
  • DD = Two-digit day (01 to 31)

For a full date and time representation: YYYY-MM-DDThh:mm:ss.s, an example would be: 2015-07-28T21:15:18.45

  • T = Separator for date and time as per ISO 8601
  • mm = Two-digit minute (00 to 59)
  • ss = Two-digit second (00 to 59)
  • s = Decimal fraction of a second, 1 or more digits

Note: The absence of a timezone in the examples means it is in local time. To specify UTC, add Z at the end of the time.

For example: 2015-07-28T21:15:18.45Z indicates UTC.

For displaying local time with a UTC offset, use formats like +hh:mm or -hh:mm as needed.

Example: 2015-07-28T21:15:18.45 in Eastern Standard Time (EST), which is 5 hours behind UTC, would be written as 2015-07-28T21:15:18.45-05:00, equivalent to 2015-07-29T02:15:18.45Z in UTC.

Understanding UTC and GMT

Though often considered the same, UTC and GMT are distinct. GMT has been a global standard for longer, frequently used when setting the time on devices like phones and computers.

UTC, which succeeded GMT, is maintained by the International Telecommunications Union. It is recommended to use UTC over GMT for more accurate timekeeping.

Naming the Months

While ISO 8601 uses numbers to avoid language issues, you can use English names for months if your content is primarily in English. For example, instead of 2015-07-28, you could write July 28, 2015, which may be clearer and more intuitive for many users.

Enhancing User Experience with Localization

Sometimes, providing services tailored to specific locales, including local time zones and languages, is essential. Numerous libraries and APIs are available to web developers for displaying dates and times relevant to the user’s region.

While you can detect the browser’s default locale via the Accept-Language header or the navigator.language or navigator.browserLanguage JavaScript objects, a more reliable method is to allow users to select their preferred locale within your application.

Once the locale is set, dates and times can be formatted accordingly. For example, using the Internationalization API, you can format a date in JavaScript with toLocaleDateString. For instance, myDate.toLocaleDateString('ko-KR') will output the date in the format used in South Korea.

Daylight Saving Time (DST)

Many countries adjust clocks forward by an hour during summer months to extend evening daylight. Be mindful of DST to ensure accurate local time representation in your services.

Avoiding Two-Digit Years

When localizing dates and times, always use the full four-digit year format. Relying on two-digit years, such as 64 or 99, can lead to confusion and errors in the future. If your system currently uses two-digit years, consider updating it.

Leap Years and Other Calendars

In concluding this post, remember some additional considerations when managing dates. If you’re handling dates manually (though generally not recommended), ensure you include February 29th in leap years.

Also, be aware that the Gregorian calendar is not the only calendar system. Several regional calendars are used globally, particularly for observing local festivals and events.