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.
Let’s say we don’t want to convert and show different date and time formats to different viewers across the world, what can we do? We pick one global format and stick with it. Here is where some standards come into play. Before we get to that, I must advise that W3C recommends that we use the ISO 8601 date format with UTC timezone.
ISO 8601 describes an internationally accepted way to represent dates and times using numbers.
And the format for complete date is;
YYYY-MM-DD, for example:
YYYY = 4 digit year
MM = 2 digit month (01=January, etc.)
DD = 2 digit day (01 to 31)
For complete date-time;
YYYY-MM-DDThh:mm:ss.s, for example:
T = To separate date and time according to ISO 8601
mm = 2 digit minute (00 through 59)
ss = 2 digit second (00 through 59)
s = Decimal fraction of a second, 1 or more digits
Please note that as no timezone has been mentioned in the above example so it is to be assumed that the time is in the local timezone. If you have decided to use UTC timezone, just add Z to the value to denote UTC
But if you wish to display local time, then you can add a timezone offset for UTC to the value in the formats
-hh:mm as needed.
For example: Let us assume
2015-07-28T21:15:18.45 is in the EST (Eastern Standard Time) timezone which lags 5 hours behind UTC timezone.
To represent it with UTC offset we write
2015-07-28T21:15:18.45-05:00 which is equivalent to the UTC time
Again Z is appended to represent that the date-time displayed is in UTC time.
They both are same yet different. By now you have probably come across GMT at least once; while setting up the date-time in your mobile phone or computer. It is the most popular timezone recognized worldwide since it has been in existence longer than UTC.
While some may say that they both are the same but they are not, UTC is a successor of GMT and is maintained by the International Telecommunications Union. It is advised to refer to time based on UTC and not GMT.
The ISO standard only used numbers in the date representation to avoid any language conflicts. But, if the contents of your web application is going to be in English, then you should consider writing down months in English rather than in numbers.
28, July, 2015 is easier to understand by many, and less confusing.
There are times when we want to be very specific with our services and would like to represent the date and time in local timezones and languages. There are many libraries and APIs available for web developers to make use of and display the dates and times as per the accessing region.
You can get the browser default locale either by interpreting the
Accept-Language request header or through the
Once you have the locale, you can format the date time according to it, for example using the Internationalization API, you can format a date using
myDate.toLocaleDateString('ko-KR') will return a formatted date in the format used in Korea by Korean-speaking natives.
In certain countries daylight savings time is done by forwarding the clocks by an hour in summer to make use of the extra sunlight available. Be aware of DST to keep up with the local times in your services.
Please take note that there is no daylight savings in the UTC timezone.
While customizing the date and time for localization do not use the two-digit format for the year at any point. We are already in the 21st century. Using years like
99 etc. will be troublesome in future. If you already have a two-digit year system in place consider changing it.
Let us end this post with some miscellaneous things to remember while dealing with dates. If you are not using any library or API for dates and like to deal with them on your own (which is not recommended nonetheless), do not forget to show the 29th of February in the input for the leap years.
Also, it is worth noting that the Gregorian calendar is not the only form of calendar available and used all over the world. There are few regional calendars that the locals follow, especially when it comes to festivities.
Powered by WPeMatico