If you're reading this blog, then you're probably subject to the dimensions of space and time. There is also a good chance that you're a developer. If both of these statements apply to you, then there is a pretty good chance that you've encountered a situation in which you've had to persist the date and time at which some interesting thing happens in your system.

How do you handle this?

The simplest thing that you can possibly do is call whatever function exists in the language you're using that gives you the current date and time in your time zone (or your server's timezone), save the thing to a disk, and be done with it. When you want to retrieve it later in the future, you just read it from disk and spit it out (maybe do some formatting) in your GUI. Done.

But there are several problems that can occur with that, depending on a lot of things (some of which you can't control):

• Your application server is in a different time zone than your users are.
• Your application server's timezone unexpectedly changes one day.
• Your database server is in a different timezone than your application server, and some new code gets added later that uses the database server's corresponding "current time" call to persist data. Now you're persisting data in two different time zones.
• Your data-mapping layer removes any notion of time zones, so when you pull the data back out you have to assume what time zone it was stored in originally. This assumption may become false in the future.
• You start collecting time as reported by your users' browsers, which are almost guaranteed to have different timezones.
• You expose an API for external systems to send time information to you and those systems begin sending it to you in UTC, so you have to convert it back to your (or your server's) timezone so that it's stored consistently everywhere.

As you can see, there are lots of places where you have to deal with time data. Things will get very slippery if you are not deliberate and careful with how you handle this data.

One thing that you can do to make things a little bit easier on yourself is to always persist times in UTC. When you create them in your system, make sure that they are in UTC. Wherever they enter your system, convert them to UTC as early as possible, before they move too deep into your system. When you pull them out of the database, leave them in UTC so that anything in your system that needs to handle them can avoid having to deal with time zones. This will save you a lot of special-case handling logic in various places. No time zones, no daylight savings, no pain.

About the only place where you should have to worry about time zones is the presentation layer of your application—where it actually matters. Your users do care about what time zone a certain piece of time is displayed in. It's easier to go about our everyday lives when the times we see are in our own time zone. On the other hand, a machine and the internals of your system should not care about time zones.

One last thing. The boundaries of your system that talk to other systems should still, if possible, communicate in UTC. The external system is still a system and shouldn't need to care about time zones, so if you can enforce that, then do it.

Keep it simple—keep timezones out of the loop whenever possible.