Handling date and time in your software

Kelvin Lai

You might think dealing with date and time information in your program is easy, but is it? You’d better check if you’ve at least considered the following:

Deciding on how much information (about the date) you need to capture
When designing a feature that needs to capture date and time, we need to decide what exactly to capture. The main thing here is to take as much data as possible to make sure that we have enough to store date and time accurately. Otherwise, we would have a hard time when we later need to perform calculations or conversions on them.
The rule of thumb is to make the users aware of the time zone of every date (and time) that they provide to our application, which can be achieved in two simple steps:
1. Ask for a default time zone during registration or profile creation
2. Ask for a specific time zone per logical date input (pre-populated with a default time zone)

Actually getting user input
When we accept input from users, we need to validate the data and still keep it easy to use:
1. Use a date picking calendar
  My recommendation is to attach a date picker which allows them to naturally select a date, while also keeping them from entering invalid dates.
2. Stick to the same input format(s)
  Accepting input in the same format can reduce ambiguousness of data and in turn protect our software from errors. Imagine if we had to process dates in both formats ‘dd/mm/yyyy’ and ‘mm/dd/yyyy’, it would’ve been painful to differentiate dates like 01/02/2019 – was it January or February. You tell me!
Storing date and time
While we have all the information about the date we’re going to save from the user, we still have to persist it clearly.
1. Always convert to UTC (Coordinated Universal Time)
  Using the time standard makes any calculation or comparison of date and time easier and error less likely to happen.
2. Ultimately format them as ISO8601 in data storage
  Saving date and time in this standard format can make it unambiguous to everyone that needs to read and process it at a later stage, and obviously better than saving it in numeric which nobody knows what it could possibly mean.
Displaying date and time
Since we have all the information we need about our date and time, we can freely convert it to any time zone and present it in a way which is useful to our users by.
1. Convert to user’s preferred time zone and explicitly show the time zone or offset
  We saved the user’s preference earlier, and now it’s time to put it back to the right zone. Don’t forget to indicate the time zone or time zone offset as a reminder to the user.
2. Be consistent
  Keeping in line with user input, we should display the date in the same format throughout the whole app, be it a standard format like ISO8601 or any other formats our user prefers.

That’s what I would see as the minimum we should do when we process date and time. Congratulations to you if you find it a waste of time – you’re not bad at all! As a dessert, I’m just going to recommend you two myth buster articles on date and time:

Let me know what you think, and until next time!