Managing date and time in the programming world

Forgetting about the Physics of Time

It’s kind of obvious, but still, you have to keep in your mind that:

Wrong data-types choices to store and handle dates

Let’s go to more practical advice.

  • Store or send it ‘as is’ (with the timezone UTC +02).
    In the case where you also need to restore the original event source time zone (a user time zone which had been used to create some event), you have to store an additional field or use the specialised data-types like ‘ TIMESTAMP WITH TIMEZONE’ in RDBMS. However, use the latest approach if you really need to know the original source timezone.
  • Convert it to the server or configured timezone if you don’t need the source timezone information. It could be a UNIX timestamp (1483221600), or ISO 2601 string (‘2016–12–31T22:00:00Z’ or ‘2016–12–31T23:00:00+01:00'), LocalDateTime in Java, etc

Handling date/times in UI/UX

One more thing. You need to correctly handle date related information in your user interfaces.

  • If you show some time information in your UI without any time zone references in it then use the user system time zone (don’t use your server timezone). The easiest way is to convert them in your ‘front-end’ right before showing on the user’s UI.
  • If you create something worldwide, you have to provide an ability to choose Time Zones in the user settings and/or in your UI views.
    Look at the example from Google :



Software Developer & Architect

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store