Takeaways from PHP Antwerp – Time functions

Normally time functions are not hard to handle, but the presentation “What every developer should know about time, no excuses” by Joeri Sebrechts in Antwerp changed my point of view.

Countries change time zones whenever they want (Russia) or change time 4 times a year (Morocco).
Bugs are made because of time miscalculations, which has stopped Twitters servers for a few hours …

It’s so difficult to define what time we actually have and how we should store it to process time in our applications. We have a lot of standards that try to organise and make life easier for people who build software (ANSI SQL92). We have also standards ( MYSQL ) and projects ( Java UTIL DATE ) that complicate working with time. Unfortunately JS’s time functions are based on Java UTIL DATE, which was not a good idea. People who work with time in JS use moment.js because it’s much better. I also had my share of problems with date objects in a datepicker. The solution was also to use moment.js.
Fun fact about birthdate: there are countries where my birth date can be like x-x-1989 because they do not care about day and month of birth. I had to change my input validation. 🙂

Other interesting facts in this presentation were his working strategies:

Time strategies:

  • We should store local time and offset;
  • Best is when we have one source of time;
  • Functions that process time should be located centrally;
  • 2017-05-31 T21:00:00 +2:00, is the format that should be stored in db;

Testing strategies:

  • We should be able to inject ‘now’ value in test cases;
  • Test the future in the past?! If our functions with time work every day from ten years ago until today, it’s highly possible they will also work in the future;
  • Test your applications with interesting dates ( unfortunately it’s hard to find any tips on the internet about “interesting dates”);

After the presentation we discussed the time format that we store in the db and we agreed that time zones can be – and sometimes even should be – stored in a separate column to avoid problematic time zone changes in case of user/programmer mistakes.