How to present date (without time element) to users from different timezones?

Question

I am wondering on how to present a date (without the time element) to users from different time zones. Let's presume that the date is stored in some database on some server that is running in some time zone (UTC+6 for example) and the application server is running on the same machine (or at least in the same time zone). The application has to handle two types of temporal values: A/ DateTime (ex. 2013-08-20 08:00 UTC) and B/ Date (ex. 2013-08-20).

A/ DateTime is easy to handle as it represent some particular point in the history. For example Moon Landing. It is stored in the UTC in the database and whenever it is presented to the client it is shifted into his time zone so it fits into his reality. So 2013-08-20 08:00 UTC = 2013-08-20 14:00 UTC+6 = 2013-08-19 22:00 UTC-10. Every client is looking at the same point in time = same event from his perspective and everything is peachy.

B/ Date = THE PROBLEM. This type of temporal value represents particular day in the history. As it doesn't have time element, it cannot be shifted to different time zones. It would seem easy to store dates with zeroed time component as 2013-08-20 00:00 UTC and present it without the time component to users. But after shifting this would result into 2013-08-19 from time zones UTC-x and that is wrong because we don't really know in which part of the world this point in the history is considered yesterday and where it is still today. Actually there are three different dates on the planet at some points (http://en.wikipedia.org/wiki/International_Date_Line).

The good example of the problem is a due date of the invoice. When you issue an invoice with due date 2013-08-20 in the time zone UTC+6 and store it on the server located in the UTC when should somebody from China pay? Is it 2013-08-19 on the UTC based server or is it still 2013-08-20?

To formulate the question:

How should be a date without the time element stored and handled to be make it possible to serve it to clients from multiple time zones (including more than 12 hours difference)? Should it be shifted? Should it stay the same date? How do you handle this scenario in your projects?

Thank you very much for reading up to this point. Any reference or idea is appreciated. Only relevant material I was able to reach was the wiki article mentioned before but to be honest I am not sure if there there is an answer to my question. Most of the articles are related to date time shifting but that part is handled well at this point.

P.S. The application server is written in Java so I am tagging this question Java related to encourage Java specific solutions if there are some.

Answer 1

First, I'm very glad to see you have put some thought into this! Many developers gloss over these details, which might be quite important depending on your application requirements.

In Java, you should use the Joda Time library for these concerns. It will help you to separate the concepts you are talking about.

• The first concept you identified is called an Instant in Joda Time. When tied to a time zone, it is called a DateTime.

• The second concept in Joda Time is called a LocalDate.

• You also identified the DateMidnight type - which I agree will probably not work for your particular needs.

It is important to realize that a LocalDate isn't really in any time zone. It's not a moment on the instantaneous time line. It's just a position on a calendar. It's mapping to a real point in time is going to depend on how you interpret it.

As Duncan pointed out in comments - it's difficult to advise you directly what you should do, because different businesses have different requirements in this regard. But here are some different approaches:

• You could bind the LocalDate to the end of the day in your customer's time zone, which means a different moment per customer for your company.

• You could bind the LocalDate to the end of the day in your company's time zone, which means a different moment for each customer.

• You could have a company policy that the business day is defined by UTC.

You should think through the practical implications of each of these options. For example, since your are talking about an invoice due date, you may want to allow a grace period.

One last point - you should always make sure that your code doesn't care what the time zone of the server is. You could easily deploy to a server that has a particular time zone, and you don't want it to break anything. Smart use of UTC or Date/Time/Offset types will solve this for particular moments in time. But since the LocalDate isn't an exact moment in time - you have to be careful to obtain it from some time zone in your application logic. Don't just ask the server for "now" and assume that is the right zone.