Learn how to manage dates in international projects.

Dates are one of the most neglected in the initial approach of a project and this can have repercussions in the medium/long term maintenance. Initially, when we start a project we simply keep the date and time without worrying too much about it, but then the project grows, requires an adaptation for the international market (e.g., a new project, a new project, etc.), and then the project is ready for the international market (e.g., a new project).internationalization) and we put all the focus on translation and localization of our website.

But is it the same time in all countries, and don't we in Spain change the time twice a year?

Although it may seem unimportant, it can cause real administrative disasters to our project, such as, for example, publishing a product in another country 6 hours earlier than expected, or scheduled tasks being executed an hour earlier or later than necessary due to the time change.

How do we handle all this?

Time Zones

In reality the international time system is something we all know and that all high-level programming languages that implement dates have built into their API, so tackling this problem just requires a bit of planning, consensus and discipline.

When we generate a date with our preferred language, it will generally do so using the configured time zone. This configuration can have different origins and priorities. Let's see some examples ordered from highest priority to lowest priority:

1. Configuration in runtimewe have just configured the language to use a default zone
2. Configuration of the framework or date library: aSome frameworks allow you to set this parameter so that the same configuration is used throughout the project (unless it is overwritten in runtime).
3. Configuration filesinterpreted languages usually allow us to set some interpreter parameters in system files.
4. Operating system configuration: sf none of the above has been configured, the system default will be used.

⚠️ Pro Tip: be careful with the database time zone configuration, because if we allow the database engine to assign dates automatically, it will do it following its own configuration, which does not necessarily have to be the same as the language or runtime.

Coordinated Universal Time (UTC)

There is a special time zone that allows us to perfectly control these differences between the different time zones, and that is the UTC zone. (Coordinated Universal Time). This zone is “zone zero”, that is, it has no time shift, we could call it the central time of the planet. In other contexts it is known as GMT (Greenwich Median Time), although UTC is the official replacement for GMT. In military jargon it is also known as Zulu Time, and allows to coordinate operations using a common time.

If we store all our dates in UTC zone, we will be able to calculate the date in any zone of the world very easily. In fact, we will not even have to do the calculations, since it is a very common function in any date library or even in the APIs of programming languages. Let's see an example in PHP:

In this case I have chosen to set the default zone at runtime, just to exemplify its use.

The interesting thing about this use is that the frontend can determine the user's time zone by different methods (domain, IP, manual user selection...) and display the dates coming from the backend adjusted to the user's time zone, without errors, without problems due to daylight savings time, etc... etc. And, simultaneously, the time of all our operations is coordinated by a unique time in the backend.

Date formats

How we want to show the date to the users is a more personal or cultural matter, based on the different countries to which we are going to show the dates. Let's see some of the most recurrent examples:

1. French format

It is the most widespread in Europe and consists of an arrangement of day, month and year, in that order.
For example:

• 13/12/1989
• 13-12-1989

It doesn't matter the use of slashes, dashes... the important thing is the order. In case of displaying the time, it is shown below separated by a blank space, with the order hour, minutes, seconds:

• 13/12/1989 11:24:26

2. American format

It is the most widespread in America. It consists of an arrangement of month, day and year, in that order. For example:

• 12/13/1989
• 12-13-1989

It doesn't matter the use of slashes, dashes... the important thing is the order. In case of displaying the time, it is shown below separated by a blank space, with the order hour, minutes, seconds:

• 13/12/1989 11:24:26

3. ISO-8601 Standard

The criterion of specifying the longest time periods first and then the shortest is followed in order. Thus, to specify a date, first write the year, then the month and then the day.

For example, to specify the date December 13, 1989 in the above example, the result would be:

• 1989-12-13

In the case of including the time it would also be bounded by the letters “T” and “Z”, for example, if the time were 11:26:24am, we would use the notation:

• 1989-12-13-13T11:26:24Z

This format is especially useful for efficient sorting and for communicating dates between different systems, since it is a well-known standard and any language implements support for this notation.

Conclusions

It is convenient that we adopt this practice on a regular basis, because when a project scales to an international level, it is more difficult to make the adaptation, since we will have millions of records in the database with the wrong time zone, and hundreds of lines of code to change because they do not take into account the time zone.

It may seem more comfortable to start without taking this into account, since the date we pass to the frontend is the one it has to show, with no conversions or anything else that would prevent you from moving forward quickly and smoothly, but as they say: is bread for today and hunger for tomorrow.

Adding this practice will bring a lot of control to our coordinated operations and to the medium/long term growth of our project.

Bibliography
Time Zones. PHP.net
ISO-8601. Wikipedia